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Abstract. This system description provides an overview of H-PILoT 
(Hierarchical Proving by Instantiation in Local Theory extensions), a 
program for hierarchical reasoning in extensions of logical theories. H- 
PILoT reduces deduction problems in the theory extension to deduc- 
tion problems in the base theory. Specialized provers and standard SMT 
solvers can be used for testing the satisfiability of the formulae obtained 
after the reduction. For a certain type of theory extension (namely for 
local theory extensions) this hierarchical reduction is sound and complete 
and - if the formulae obtained this way belong to a fragment decidable 
in the base theory - H-PILoT provides a decision procedure for testing 
satisfiability of ground formulae, and can also be used for model gener- 
ation. 
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1 Introduction 

H-PILoT (Hierarchical Proving by Instantiation in Local Theory extensions) is 
an implementation of the method for hierarchical reasoning in local theory exten- 
sions presented in [GSW04,GSW06,Sof05,Sof07]: it reduces the task of checking 
the satisfiability of a (ground) formula over the extension of a theory with addi- 
tional function symbols subject to certain axioms (a set of clauses) to the task 
of checking the satisfiability of a formula over the base theory. The idea is to 
replace the set of clauses which axiomatize the properties of the extension func- 
tions by a finite set of instances thereof. This reduction is polynomial in the size 
of the initial set of clauses and is always sound. It is complete in the case of 
so-called local extensions [Sof05]; in this case, it provides a decision procedure 
for validity for the universal fragment of the theory extension (or alternatively 
for satisfiability of ground clauses w.r.t. the theory extension) if the clauses ob- 
tained by the hierarchical reduction belong to a fragment for which satisfiability 
is decidable in the base theory. The satisfiability of the reduced set of clauses is 
then checked with a specialized prover for the base theory. 

State of the art SMT provcrs such as CVC3 [BT07], Yices [DdM06a,DdM06b] 
and Z3 [dMB08,BdM09] are very efficient for testing the satisfiability of ground 
formulae over standard theories, but use heuristics in the presence of universally 
quantified formulae, hence cannot detect satisfiability of such formulae. H-PILoT 
recognizes a class of local axiomatizations, performs the instantiation and hands 
in a ground problem to the SMT provers or other specialized provers, for which 
they are know to terminate with a yes/no answer, so it can be used as a tool for 
steering standard SMT provers, in order to provide decision procedures in the 
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case of local theory extensions. H-PILoT can also be used for generating mod- 
els of satisfiable formulae; and even more, it can be coupled to programs with 
graphic facilities to provide graphical representations of these models. Being a 
decision procedure for many theories important in verification, H-PILoT is ex- 
tremely helpful for deciding truth or satisfiability in a large variety of verification 
problems. 

This is an extended version of the description of H-PILoT presented at CADE 
22 [ISS09]. 

2 Theoretical background 

Many problems in mathematics and computer science can be reduced to proving 
the satisfiability of conjunctions of literals in a background theory (which can be 
the extension of a base theory with additional functions - e.g., free, monotone, or 
recursively defined - or a combination of theories) . Considerable work has been 
dedicated to the task of identifying situations where reasoning in extensions 
and combinations of theories can be done efficiently and accurately. The most 
important issues which need to be addressed in this context are: 

(i) finding possibilities of reducing the search space without losing completeness, 
and 

(ii) making modular or hierarchical reasoning possible. 

In [GM92,McA93,GM02], Givan and McAllester introduced and studied the so- 
called "local inference systems" , for which validity of ground Horn clauses can 
be checked in polynomial time. A link between this proof theoretic notion of 
locality and algebraic arguments used for identifying classes of algebras with 
a word problem decidablc in PTIME [Bur95] was established in [GanOl]. In 
[GSW04,GSW06,Sof05] these results were further extended to so-called local 
extensions of theories. Locality phenomena were also studied in the verification 
literature, mainly motivated by the necessity of devising methods for efficient 
reasoning in theories of pointer structures [MN05] and arrays [BMS06] . 

In [IJSS08] we showed that these results are instances of a general concept of 
locality of a theory extension - parameterized by a closure operator on ground 
terms. The main idea of locality and local extensions is to limit the search space 
for counterexamples (hence the name). 

2.1 Local theory extensions 

We consider the following setup. Let To be a theory in some signature S . We 
consider extensions 7i = 7oU/C of % with function symbols in a set Si (extension 
functions) whose properties are axiomatized by a set JC of (universally closed) 
So U Zi-clauses. Let S c be an additional set of constants. 

Task. Let G be a set of ground So U Si U i7 c -clauses. We want to check whether 
or not G is satisfiable w.r.t. % U /C. 
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Method. Let fC[G] be the set of those instances of K, in which every subterm 
starting with an extension function is a ground subterm already appearing in 
K, or G. If G is unsatisfiable w.r.t. To U 1C[G] then it is also unsatisfiable w.r.t. 
% U JC. The converse is not necessarily true. 

Definition 1. We say that the extension To U K of To is local if it satisfies the 
following condition 1 : 

(Loc) For every set G of ground So U Si U S c -clauses it holds that 
% U K U G \= _L i/ and or% i/ U /C[G] UG(=1 

Thus, the method is sound and complete for local theory extensions. 

Theorem 1 ([Sof05]). Assume that the extension To C T = 7oU/C is local and 
let G be a set of ground clauses. Let K? U G° U D be the purified form of K, U G 
obtained by introducing fresh constants for the S\-terms, adding their definitions 
d w f(t) to D, and replacing f(t) in G and K\G] by d. (Then S\-functions occur 
only in D in unit clauses of the form d w f(t).) The following are equivalent. 

(1) 7oU/CUG has a (total) model. 

(2) To U K,[G] U G has a partial model where all subterms of K. and G and all 
So- functions are defined. 

(3) To U JC° U G° U Con has a total model, where 

Con := { A"=i c * ~ d i c ~ d \ Z( c i' •••' c «) ~ C '/( d l' •••: d n) ~ rf S £>}. 

A variant of this notion, namely if'-locality, was also studied, where the set of 
instances to be taken into account is /C^G)], where if - is a closure operator 
which may add a (finite) number of new terms to the subterms of G. We also 
analyzed a generalized version of locality, in which the clauses in /C and the set 
G of ground clauses are allowed to contain first-order i7o-formulae. 

2.2 Examples of local theory extensions 

Among the theory extensions which we proved to be local or tp'-local in previous 
work are: 

— a fragment of the theory of pointers with stored scalar information in the 
nodes introduced in [MN05], further analyzed in [IJSS08,FIJS10]; 

— a fragment of the theory of arrays with integer indices, and elements in a 
given theory introduced in [BMS06], further analyzed in [LJSS08]; 

— theories of functions over an ordered domain or over a numerical domain 
satisfying monotonicity or boundedness conditions [Sof05,Sof06a,SI07a]; 

— various combinations of such extensions [Sof07,USS08]. 

We can also consider successive extensions of theories: To Q % U /Ci C • • • C 
7o U tCi U ■ • ■ U K. n . If every variable in Id occurs below a function symbol in Si, 
this reduction process can be iterated [IJSS08]. 

For local theory extensions, Theorem 1 allows us to reduce the original prob- 
lem to a satisfiability problem over the base theory To- 

1 It is easy to check that the formulation we give here and that in [Sof05] are equivalent. 
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3 Implementation 

The software system H-PILoT (Hierarchical Proving by Instantiation in Local 
Theory extensions) for hierarchical reasoning in local theory extensions is imple- 
mented as follows: A given proof task (set of ground clauses), over the extension 
of a theory with functions axiomatized by a set of clauses, is reduced to an equi- 
satisfiablc ground problem over the base theory in the manner of Theorem 1. 
After H-PILoT has carried out this reduction, it hands over the transformed 
problem to a dedicated prover for the base theory. This reduction is always 
sound. For local theory extensions the hierarchical reduction is sound and com- 
plete. If the formulas obtained in this way belong to a fragment decidablc in 
the base theory, H-PILoT provides a decision procedure for testing satisfiabil- 
ity of ground formulas. If the reduced formulas are satisfiable (modulo the base 
theory), H-PILoT can be used for model generation, which is of great help in 
detecting and localizing errors. 

3.1 Generalities 

H-PILoT is implemented in Ocaml 2 . The system, together with a manual and ex- 
amples, can be downloaded from www.mpi-inf .mpg.de/~ihlemann/software/. 
There is both a 32-bit and a 64-bit Linux version available. 

To improve user-friendliness, a clausifier has also been integrated into H-PILoT 
(Sect. 12). H-PILoT recognizes a class of local axiomatizations; it has advanced 
abilities to handle the common data structures of arrays (Sect. 11.1) and point- 
ers (Sect. 11. 2) 3 . H-PILoT performs the instantiation and hands in a ground 
problem to the SMT provers or other specialized provers, for which they are 
known to terminate with a yes/no answer, so it can be used as a tool for steering 
standard SMT provers, in order to provide decision procedures in the case of 
local extensions. The provers integrated with H-PILoT are the general-purpose 
prover SPASS ([WDF+09]); the SMT-solvers Yices ([DdM06a,DdM06b]), CVC3 
([BT07]) and Z3 QdMB08]); and the prover Redlog ([DS97]) for non-linear real 
problems. State-of-the-art SMT provers, such as the ones above, are very effi- 
cient for testing the satisfiability of ground formulas over standard theories, such 
as linear arithmetic (real, rational or integer), but use heuristics in the presence 
of universally quantified formulas, hence, cannot reliably detect satisfiability of 
such formulas. However, if SMT solvers are used for finding software bugs, be- 
ing able to detect the actual satisfiability of satisfiable sets of formulas is crucial 
(cf. [dM09,dMB08,GdM09,BdM09]). For local theory extensions, H-PILoT offers 
the possibility of detecting satisfiability and of constructing models for satisfiable 
sets of clauses. On request, H-PILoT provides an extensive step-by-step trace of 
the reduction process, making its results verifiable (Sect. 15.2). 

H-PILoT has been used in large case studies, where its ability (1) to handle 
chains of extensions, (2) to detect unsatisfiability and satisfiability, and (3) to 
construct models of satisfiable sets of clauses has been crucial. 

2 http : / /caml . inria . f r/ ocaml/ index . en . html 

3 H-PILoT automatically detects whether a given specification falls within the local 
fragment of these theories. 
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3.2 Structure of the program 



The main algorithm which hierarchically reduces a decision problem in a the- 
ory extension to a decision problem in the base theory can be divided into a 
preprocessing part, the main loop and a post-processing part; see Figure 1. 



Preprocessing. The input is read and 
parsed. If it is detected to be in SMT for- 
mat, we set the options to "use arithmetic" 
(e.g., +, — arc predefined). If the input is 
not in clause normal form (CNF), it is trans- 
lated to CNF, then the input is flattened and 
linearized. The program then checks if the 
clauses in the axiomatization given are lo- 
cal extensions and sets the flag -local to 
true/false. This ends the preprocessing phase. 

Main algorithm. The main loop proceeds as 
follows: We consider chains of extensions To Q 
Ti C • • • C T n , where % = % U \J l j=1 K,j of % 
with function symbols in a set (extension 
functions) whose properties are axiomatized 
by a set /Q of (77 U Uj = i £j)-clauses. 

Let i = n. As long as the extension level 
i is greater than 0, we compute /Q[G] 
for arrays). If no separation of the extension 
symbols is required, we stop here (the result 
will be passed to an external prover that can 
reason about the extension of the theory To 
with free function symbols in S n ). Otherwise, 
we perform the hierarchical reduction by pu- 
rifying K.i and G (to K, ? , G° respectively) and 
by adding corresponding instances of the con- 
gruence axioms Con^. To prepare for the next 
iteration, we transform the clauses into the 
form Vx.<?V/Ci (compute prenex form, skolem- 
ize). If K,i[G] (i > 1) is not ground, we quit 
with a corresponding message. Otherwise we 
V := T\ {/Q}. We flatten and linearize K,' 
reached G' is handed to an external prover. 



Preprocess 



clausify 



Main Loop 




quit 



J 



give to | local := false 

prover 




yes 

not local 



return 
"unsatisfiable" 



Postprocess 



Fig. 1. H-PILoT Structure 
set G' := /C° A G° A Con, and 
and decrease i. If level i = is 



Post-processing. If the answer is "unsatisfiable" then G ^r n -L- If the answer 
is "satisfiable" and all extensions were local, then G is satisfiable w.r.t. T n and 
we know how to build a model. If the answer is satisfiable but we do not know 
that all extensions are local, or if the instantiated clauses (of level > 1) were not 
ground, we answer "unknown" . 
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4 Modules of H-PILoT 

We present the different parts of H-PILoT in more detail. 

4.1 Preprocessing 

H-PILoT receives as input a many-sorted specification of the signature; a speci- 
fication of the hierarchy of local extensions to be considered; an axiomatization 
/C of the theory extension(s); a set G of ground clauses containing possibly ad- 
ditional constants. H-PILoT allows the following preprocessing functionality. 

Translation to clause form. H-PILoT provides a translator to clause normal 
form (CNF) for ease of use. First-order formulas can be given as input; H-PILoT 
translates them into CNF. In the present implementation, the CNF translator 
does not provide the full functionality of FLOTTER ([NW01]) - it has only 
restricted subformula renaming - but is powerful enough for most applications. 

Flattening/linearization. Methods for recognizing local theory extensions 
usually require that the clauses in the set /C extending the base theory are 
flat and linear, which does nothing to improve readability. If the flags -linearize 
and/or -flatten are used then the input is flattened and/or linearized (the gen- 
eral purpose flag -preprocess may also be used). H-PILoT allows the user to 
enter a more intelligible non-flattened version and will perform the flattening 
and linearization of JC. 

Recognizing syntactic criteria which imply locality. Examples of local 
extensions include (fragments of) the theories of the common data structures: the 
theory of arrays (see Section 11.1) and the theory of pointers (see Section 11.2), 
respectively (and also iterations and combinations thereof). In the preprocessing 
phase H-PILoT analyzes the input clauses to check whether they are in one of 
these fragments. 

- If the flag -array is on, H-PILoT checks if the input is in the "array property 
fragment" . 

- If the keyword "pointer" is detected, H-PILoT checks if the input is in the 
appropriate pointer fragment and adds missing "nullability" terms, i.e., it 
adds premises of the form "t ^ null", in order to relieve the user of this 
clerical labor. 

If the answer is "yes" then we know that the extensions we consider are local, 
i.e., that H-PILoT can be used as a decision procedure. 

4.2 Main algorithm 

The main algorithm hierarchically reduces a decision problem in a theory exten- 
sion to a decision problem in the base theory. 

Given a set of clauses K. and a set of ground clauses G, the algorithm we 
use carries out a hierarchical reduction of G to a set of formulas in the base 
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theory. It then hands over the new problem to a dedicated prover such as Yices, 
CVC3 or Z3. H-PILoT is also coupled with Redlog (for handling non-linear real 
arithmetic) and with SPASS 4 . 

Loop. For a chain of local extensions: 



To c 7! = % U £1 c T 2 = To U K x U /C 2 
C ... C 7; = 7uU/Ci U ... U/C„. 



a satisfiability check w.r.t. the last extension 
can be reduced (in n steps) to a satisfiability 
check w.r.t. 7o- The only caveat is that at each 
step the reduced clauses /C°UG°UCon° need to 
be ground. Groundness is assured if each vari- 
able in a clause appears at least once under 
an extension function. In that case, we know 
that at each reduction step the total clause 
size only grows polynomially in the size of G 
([Sof05]). H-PILoT allows the user to specify 
a chain of extensions by tagging the extension 
functions with their place in the chain (e.g., 
if / belongs to /C3 but not to /Ci U IC2 it is 
declared as level 3). 

Let i = n. As long as the extension level i 
is larger than 0, we compute /Q[G] (JCi[\P(G)] 
in case of arrays). If no separation of the ex- 
tension symbols is required, we stop here (the 
result will be passed to an external prover). 
Otherwise, we perform a hierarchical reduc- 
tion by purifying /Cj and G (to /C°, G° respectively) and by adding corresponding 
instances of the congruence axioms Corii. To prepare for the next iteration, we 
transform the clauses into the form Wx.<P\/ JCi (compute prenex form, skolemize). 
If /Cj[G]//Q ) is not ground, we quit with a corresponding message. Otherwise our 
new proof task G' becomes G' := K.® A G° A Con^, our new extension clauses are 
K! := )Ci-i and our new base theory becomes T' := 77— 1 \ {/Q-i}. We flatten 
and linearize K! and decrease i. If level i = is reached, we exit the main loop 
and G' is handed to an external prover. Completeness is guaranteed if all exten- 
sions are known to be local and if each reduction step produces a set of ground 
clauses for the next step. 



Extension n: T n 


In 










Extension 1: T1 


*1 


Base theory: T 






\ 


Extension 1: ^ 




G 


Base theory: T 




n , 


\ 


Base theory: T 







iiiri 



Yices 



CVC 



Z3 



SPASS 



Red Log 



4.3 Post-processing 

Depending on the answer of the external provers to the satisfiability problem 
G n , we can infer whether the initial set G of clauses was satisfiable or not. 



4 H-PILoT only calls one of these solvers once. 
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— If G n is unsatisfiable w.r.t. 7o then we know that G is unsatisfiable. 

— If G n is satisfiablc, but H-PILoT failed to detect this, and the user did not 
assert the locality of the sets of clauses used in the axiomatization, its answer 
is "unknown" . 

— If G n is satisfiable and H-PILoT detected the locality of the axiomatization, 
then the answer is "satisfiablc". In this case, H-PILoT takes advantage of 
the ability of SMT-solvers to provide counterexamples for the satisfiable set 
G n of ground clauses and specifies a counterexample of G by translating the 
basic SMT-model of the reduced proof task to a model of the original proof 
task. This improves readability greatly, especially when we have a chain of 
extensions. The counterexamples can be graphically displayed using Math- 
ematica (cf. Section 15.3). This is currently done separately; an integration 
with Mathematica is planned for the future. 

5 The input grammar 

The input file consists of a declaration part (for function symbols in the base 
theory, for extension functions, for relations, and constants), specifications of 
the types and of the base theory, a part containing axiomatizations of base the- 
ory/extension functions; and a part containing the set of ground clauses whose 
satisfiability is being checked. 

(start) ::= (base-functions) (extension_functions) (relations) (constants) (interval) 
(baseTheory) (formulasOrClauses) (groundformulas) (query) 

5.1 Declarations 

Type declarations: We allow for declarations of standard types: 

(domain) ::= bool | int | real | pointer | pointer* (int) 
| scalar | free | f ree# (int) 

Declarations of simple types such as intervals are also allowed: 

(interval) ::= e 

| Interval := (int) (sm) (identifier); 

| Interval := (identifier) (sm) (int); 

| Interval := (int) (sm) (identifier) (sm) (int); 

(int) ::= any non-negative number, 
(sm) ::= <= | < 

Further details are given in Section 10. 

Function and relation declarations. The declaration part contains sort and 
type declarations for the function symbols in the base theory, for the extension 
function symbols, for the relation symbols and for the constants: 
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(base-functions) ::= Base_f unctions := { (function-list) } 
(extension-functions) ::= Ext ens ion Junctions := { (function-list) } 
(relations) ::= Relations := { (relation-list) } 
(constants) ::= e | Constants := { constant Jist } 

(constant-list) ::= (constant) (additional-constants) 
(additional-constants) ::= e | , (constant) (additional-constant) 

(constant) ::= ( (identifier) , bool ) 

| ( (identifier) , int ) 

| ( (identifier) , real ) 

| ( (identifier) , scalar ) 

| ( (identifier) , pointer ) 

| ( (identifier) , pointer* (int) ) 

| ( (identifier) , free ) 

| ( (identifier) , f ree# (int) ) 



(function_list) ::— e | (function) (additional-functions) 
(additional-functions) ::= e | , (function) (additional-functions) 
(relation-list) ::— e \ (relation) (additional-relations) 
(additional-relations) ::= e | , (relation) (additional-relations) 

We allow for predefined relation declarations (e.g. for relations such as < or < 
as well as for new relation declarations. In each case we specify together with 
the relation symbols also their arity. 

(relation) ::= ( (uneqs) , (int) ) | ( (identifier) , (int) ) 

We allow for several forms of function declaration: We can declare the number 
of arguments of the function ((1),(2)); the number of arguments and the level 
(for predefined arithmetical operations over the integers (3), or reals (4) or for 
uninterpreted functions (5)); the number of arguments, the level, and the sort 
of the domain and codomain (without repetitions if the domain and codomain 
are the same (6); separately specified if they are different (7)). 



(function) ::= ( (identifier) , (int) ) (1) 

( (arithop) , (int) ) (2) 

( (arithop) , (int) , (int) , int ) (3) 

( (arithop) , (int) , (int) , real ) (4) 

( (identifier) , (int) , (int) ) (5) 

( (identifier) , (int) , (int) , (domain) ) (6) 

( (identifier) , (int) , (int) , (domain) , (domain) ) (7) 



At the moment declarations of functions which accept arguments of different 
sorts are not supported. 
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5.2 Axiomatizations 

We support axiomatizations for the base theory: 

{base-theory) ::= e | Base := (clauseJist) 

axiomatizations of the properties of the extension functions: 

(formulasOr Clauses) ::~ e \ (formulas) \ (clauses) 

(formulas) (clauses) \ (clauses) (formulas) 

as well as input of the ground formulae whose (un)satisfiability is being checked: 
(formulas) ::= Formulas := (formulajist) 

(formulajist) ::= (formula) \ (formula) ; (additionaLformulas) 
(additionaLformulas) ::= e \ (formula) ; (additionaLformulas) 

(formula) ::= (atom) 

NOT ( (formula) ) 

OR ( (formula) (formula-plus) ) 
| AND ( (formula) (formula_plus) ) 
| ( (formula) — > (formula) ) 
| ( (formula) < — > (formula) ) 
| ( FORALL (variables) ) . (formula) 
j ( EXISTS (variables) ) . (formula) 

(formula_plus) ::— , (formula) (formula_star) 
(formula_star) ::— e \ , (formula) (formula_star) 
(ground-formulas) ::= e \ Ground_Formulas := (formulajist) 

(query) ::= Query := (ground-clauses) 

(clauses) ::— Clauses := (clauseJist) 

(base-dauseJist) ::= e | (clause) ; (additionaLbase-dauses) 
(additionaLbase-dauses) ::= e | (base-clause) ; (additionaLbase-dauses) 
(base_clause) ::— (clausematrix) \ (universalQuantifier) (clausematrix) 
(clauseJist) ::= (clause) \ (clause) ; (additionaLclauses) 
(additionaLclauses) ::= e | (clause) ; (additionaLclauses) 

(clause) ::~ (clausematrix) 

| (universalQuantifier) (clausematrix) 
| { (formula) } OR (clausematrix) 

| (universalQuantifier) { (formula) } OR (clausematrix) 
{ (formula) } — > (clausematrix) 

| (universalQuantifier) { (formula) } — > (clausematrix) 
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(universalQuantifier) ::= ( FDRALL (variables) ) . 
(variables) ::= (name) (additional-variable) 
(additionaLvariables) ::= e | , (name) (additionaLvariables) 
(ground-clauses) ::= e \ (clausematrix) ; (ground-clauses) 
(clausematrix) ::— (literal) \ (disjunctive-clause) \ (sorted-dause) 

(disjunctive-clause) ::= OR ( (literal) (literaLplus) ) 
(UteraLplus) ::— , (literal) (literaLstar) 
(UteraLstar) ::— e | , (literal) (literaLstar) 

(sorted-dause) ::— (atomJist) — > (atomJist) 
(atomJist) ::= e | (atom) (atomstar) 
(atomstar) ::= e | , (atom) (atom_star) 

(literal) ::= (atom) | NOT ( (atom) ) 

(atom) ::— (equality_atom) \ (ineq_atom) \ (predicate-atom) 
(equality _atom) ::— (term) = (term) 
(ineq_atom) ::= (term) (uneqs) (term) 

(predicate_atom) ::— (identifier) [ (term) (additional-terms) ] 
(arguments) ::= (term) (additional-terms) 
(additional-terms) ::— e \ , (term) (additional-terms) 

(term) ::= (name) 

| (operator) ( (arguments) ) 

(array) ( (arguments) ) 
| (update) ( (arguments) ) 

(term_arith) (arithop) (term-arith) 

(term-arith) ::= (name) 

| (operator) ( (arguments) ) 

| ( (term-arith) (arithop) (term-arith) ) 

(arithop) ::= + | - | * | / 
(uneqs) ::= <= | >= | < | > 
(operator) ::= (identifier) 

(array:) write ( (identifier) , (term) , (term) ) 
| write ( (array) , (term) , (term) ) 

(update) ::= update ( (identifier) , (term) , (term) ) 
| update ( (update) , (term) , (term) ) 

(name) ::= (identifier) 

(identifier) ::= any string consisting of letters and numbers starting with a letter. 
It may end with "' ". 



System Description: H-PILoT 13 



6 Parameters of H-PILoT 

H-PILoT has several input parameters controlling its behavior. They can be 
listed by calling hpilot . opt -help. 



-min Use minimal locality. Currently, this is only relevant 

for the array property fragment. 
-prClauscs Produce output: print all the clauses calculated and used. 
-noProver Do not hand over to prover, just produce output, 
-arith Use arithmetic, 'plus', '+','-' etc. are predefined. 

Numerals (names for integers) must be used preceded by 

underscore _, e.g., '_3'. 
-yices Use Yices as background solver: 'plus', '+' etc. 

are predefined as are the order relations <,>,<,>. 

Numbers can also be given in the input. 

Numbers are integers by default 

(use '-real' for real numbers), 
-eve Use CVC as background solver. 

Arithmetic is predefined as with '-yices'. 
-z3 Use Z3 as background solver. 

Arithmetic is predefined as with '-yices'. 
-flatten Flatten clauses first, 

-linearize Linearize clauses first. 
-flattenQuery Flattens the proof task first. 

-preprocess Preprocess input: flatten/linearize clauses, flatten proof task. 

In array-context: split clauses which contain inequalities 

like i ^ j into two clauses. 
-noScparation Stop at calculating the instances IC[G]. Don't introduce 

names for extension terms and don't reduce to base theory. 
-unPscudofy Eliminate pseudo-quantifiers like Mi.i = 3... 

before handing over to a prover. 5 
-noProcessing No computation. Just translate into prover syntax and 

hand over. Overrides '-preprocess'. 

When using this flag one should provide the domains 

of functions too. When used in combination with CVC 

there may arise problems with boolean types. 6 
-clausification Toggle clausification (true/false). Default is 'true'. 



'false' implies '-noProcessing'. 
-real Use reals instead of integers as the default type, 

-redlog Call Redlog for base prover. Assumes '-real', 

-version Print version number. 



This is automatically carried out if we have a multiple-step extension. This is because 
the next step can only be carried out if the current step resulted in ground clauses. 
6 This is because CVC only provides booleans as bit- vectors of length 1. The type 
'BOOLEAN' is the type of formulas. 
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-frccType 


Enables the use of an unspecified type 'free' 
in addition to 'real' and 'hit'. 
Only CVC, Z3 and Yices accept free types. 
Yices is default. 


-renameSubformulas Toggles the renaming of subformulas 




during clausification (true/false). 




Subformula renaming avoids exponential growth. 




Default is "true". 


-verbosity 


Verbosity level (0,1,2). 

From taciturn to garrulous. 

To be used in conjunction with '-prClauses'. 

Default is 


-arrays 


Use settings for array. 

This combines '-preprocess', '-min' and '-arith'; 
It also splits clauses on negative equalities. 


-model 


Gives a counter-model for satisfiable proof tasks. 
Needs Yices or CVC (implies Yices by default). 


-smt 


Produce SMT-LIB output 
without calling a prover. 


-isLocal 


Use this flag (true/false) to tell the program 

whether all the extensions are local or not. 

This matters only if H-PILoT 

cannot derive a contradiction. 

In that case this means that there really is none 

only if the extensions are local. 

Default is false. 


-help 


Display list of options 



7 Error handling 

In case there is a parsing error one can use 
export OCAMLRUNPARAM= ' p ' (in bash syntax). 

This produces a walk-through of the parsing process, which is of great help in 
localizing syntax errors. To turn it back off use 

export C AMLRUNP ARAM= ' ' . 

8 Application areas 

H-PILoT has applications in mathematics, multiple-valued logics, data- structures 
and reasoning in complex systems. 

Mathematics. An important example of local extensions are extensions with 
monotone functions over partially ordered sets [SI07a,SI07b]. We will give an 
example of how to use H-PILoT on problems involving monotonicity in Section 9 
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below. Another example from mathematics is an extension with free functions, 
i.e., we have an empty set of extension clauses JC but the proof task G contains 
new function symbols. Even in this simple case, local and hierarchical reasoning is 
useful, because expanding the signature might already derail a back-end prover. 
For instance, consider real arithmetic. Linear arithmetic is tractable and can be 
handled quite efficiently by state-of-the-art SMT-solvers. Non-linear arithmetic 
is another matter, however (cf. [FHT+07,BPT07]). Here the options are more 
limited. To handle non-linear real arithmetic, H-PILoT is integrated with the 
prover Redlog ([DS97]). Since Redlog uses quantifier elimination for real closed 
fields, it relics on a fixed signature. In a case like this, H-PILoT can be employed 
as a preprocessor that eliminates the new function symbols in the proof task, 
allowing the user to employ free function symbols together with (non-linear) real 
arithmetic. Another example from mathematics, taken from [Sof05], is that of a 
Lipschitz function. There it was shown that any extension of the real numbers 
with a Lipschitz function is local. 

Multiple- valued logics. Another important application area of local reasoning 
and, by the same token, H-PILoT is reasoning in multiple-valued logics. These 
logics have more than two truth values, in fact they allow as truth values the 
whole real interval of [0,1]. The semantics are often given algebraically. For 
example, the class A4V of all MV-algebras is the quasi-variety generated by 
the real unit interval [0, 1] with connectives {V, A, o, (cf. [SI07a,SI07b]). The 
connectives for these algebras can be defined in terms of real functions and 
relations. Hence, these connectives can be seen as the extension functions of a 
definitional extension over the reals, which is local. One may, therefore, reduce 
universal validity problems over the class of .MV-algebras, say, to a constraint 
satisfiability problem over the unit interval [0, 1] (cf. [SI07a,SI07b]). This allows 
one to use solvers for the real numbers to discharge proof tasks over multiple- 
valued logics. We will give an example of this in Section 10.1. 

Data structures. The ubiquitous data structures of arrays and lists satisfy 
locality conditions if we confine ourselves to appropriate fragments of their the- 
ories. This matters in particular if we have satisfiable problems. In order to have 
a full decision procedure - one that is also able to give the correct answer for 
satisfiable problems - one has to stay inside of these fragments. H-PILoT auto- 
mates this task: it will check whether a given problem lies inside the appropriate 
fragment of the theory of arrays or pointers, respectively, and give the answer 
"satisfiable" only if this is the case. Otherwise, H-PILoT will give the answer 
"unknown" and warn the user that the problem did not fall inside the local 
fragment. (For unsatisfiable problems this never matters. If we can derive a con- 
tradiction from the local instances alone, we can derive one from the universal 
extension axioms a fortiori.) 

Reasoning in complex systems. In order to be able to handle complex real life 
systems which mix many theories, a stratified approach is expedient: we consider 
chains of local extensions (cf. [JSS07]). This feature is supported in H-PILoT. 
The user simply has to tag extension functions with their respective level in the 
chain. A reduction is then carried out iteratively by the program. A full-fledged 
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reduction is possible provided the reduced theory clauses are ground at each 
level of the extension chain. H-PILoT has been part of a vertically integrated 
tool chain, checking invariants of a transition system modeling a European train 
controller system (see Section 15.1). The correctness of the model was shown au- 
tomatically [IJSS08]. The underlying track topology was complex and dynamic, 
making H-PILoT's ability to decide the pointer fragment essential. It was also a 
great help in practice, due to its ability to provide (readable) counterexamples 
in the cases where the problem together with the axiomatization was satisfiable. 
This aided the modeler in finding gaps in the specification. 

9 Examples 

We illustrate the way H-PILoT is implemented and can be used on two examples. 
9.1 Monotone functions 

We consider as base theory 7o the theory of a partial order, and its extension 
with two monotone functions / and g. 

That is, our base theory 7o consists of the axioms for reflexivity, transitivity and 
anti-symmetry. 

(1) Vx. x < x. 

(2) Vx, y.x<yAy<x^x = y. 

(3) Vx, y,z.x<yAy<z^x<z. 

The extension we consider consists of the two new function symbols together 
with the clauses 1C expressing their monotonicity. 

(1) Vx,y.x<y->f{x)<f(y). 

(2) Vx,y. x < y ->■ g(x) < g(y). 

We want to show that 

% U JC \= c < ci < d 1 Ac 2 < dihd 2 < c 3 Ad 2 < c 4 A/(di) < g{d 2 ) -> /(c ) < ff(c 4 ). 

Expressed as a satisfiability problem of the form "7o U JC U G |=_L?" , where: 

G = c < ci < di Ac 2 < di Ad 2 < c 3 Ad 2 < c 4 A/(di) < g(d 2 ) A-./(c ) < g(c 4 ). 

As an input file for H-PILoT this looks as follows (we use "R" as order relation 
because < is reserved). 



7, Two monotone functions over a poset . 
7, Status: unsatisf iable 

Base_f unctions : ={} 

Extension_f unctions :={ Cf , 1), Cg, 1)} 
Relations :={(R, 2)} 
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% R is partial order 

Base := CFQRALL x) . R[x, x] ; 

(FQRALL x,y,z). R[x, y] , R[y, z] — > R[x, z] ; 

CFQRALL x,y). R[x, y] , R[y, x] — > x = y; 

Clauses := (FORALL x,y). R[x, y] — > R[f(x), f(y)]; 

(FQRALL x,y). R[x, y] — > R[g(x), g(y)] ; 

query := R[cO, cl] ; 

R[cl, dl] ; 

R[c2, dl] ; 

R[d2, c3] ; 

R[d2, c4] ; 

R[f (dl), g(d2)] ; 

NOT(R[f(cO), g(c4)]); 



In this case we have no function symbols in the base theory and two functions 
symbols / and g of arity 1 in the extension clauses. This is expressed by: 

Base_f unctions :={} 

Extension_functions:={(f , 1), (g, 1)} 

We have only one relation in our (base) clauses, namely 'R', with arity 2. This 
we express by: 

Relations :={(R, 2)}. 

For technical reasons, relations require square brackets for their arguments in 
H-PILoT as seen above. The symbols <=, <, >= and > are reserved for arith- 
metic over the integers or over the reals. They may be written infix and there 
are provers (e.g., Yices, CVC) that "understand" arithmetic and orderings. We 
wouldn't have needed to axiomatize '<' at all. 

However, the above problem is more general. It concerns every partial order 
not only orderings of numbers. By default, H-PILoT calls SPASS. SPASS has 
no in-built understanding of orderings and, thus, <= would be just an arbitrary 
symbol. For clarity we used the letter 'R'. 

As for the syntax of clauses, one should note that the syntax of H-PILoT requires 
that each clause must end with a semicolon, be in prenex normal form and all 
names meant to be (universal) variables must be explicitly quantified. 

Every name which is not explicitly quantified will be considered a constant! 

As we can see in our proof task. 

Proof Task := R[cO, cl] ; 
R[cl, dl] ; 
R[c2, dl] ; 
R[d2, c3] ; 
R[d2, c4] ; 
R[f (dl), g(d2)] ; 
NOT(R[f(cO), g(c4)]); 

Note further that because the background theory, extension theory and the proof 
task must all be clauses 7 , we need to break up the conjunction in our original 

7 In fact, the extension clauses might be more general as we will see later. 
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proof task into a set of unit clauses. A non-unit clause may be written as above 
in a "sorted" manner tpi,...,<p n — V fa, fa for <pi A ... A ip n — > fa V ... V fa,, i.e., 
as an implication with the negated atoms of the clause in the antecedent and 
the (positive) atoms in the consequent (the operator — > is reserved for sorted 
clauses) or as an arbitrary disjunctions of literals. 

The name of the input files for H-PILoT can be freely chosen, although it is 
customary to have them have the suffix ".loc" . Suppose we have put the above 
problem in a file named mono_f or_poset . loc, then we can run H-PILoT by 
calling 

hpilot . opt mono_f or_poset . loc 

H-PILoT will parse the input file, carry out the reduction and then will hand 
over the reduced problem to SPASS (using the same name but with the suffix 
".dfg"). SPASS terminates quickly with the result that a proof exists 



SPASS beiseite: Proof found. 
Problem: mono_f or_poset . df g 

SPASS derived 35 clauses, backtracked clauses and kept 41 clauses. 

SPASS allocated 496 KBytes. 

SPASS spent 0:00:02.32 on the problem. 

0:00:00.00 for the input. 

0:00:00.00 for the FL0TTER CNF translation. 
0:00:00.00 for inferences. 
0:00:00.00 for the backtracking. 
0:00:00.10 for the reduction. 



meaning that the set of clauses is inconsistent, as we wanted to show. 
One can see the full reduction process by using the option -prClauses. 

9.2 Arrays 

For a more complicated example, let us consider an algorithm for inserting an 
element x into a sorted array a with the bounds I and u. We want to check that 
the algorithm is correct, i.e., that the updated array a' remains sorted. This 
could be an invariant being checked in a verification task. 
There are three different cases. 

— x could be smaller than any element in a (equivalently, x < a[l}), 

— x could be greater than any element of a (x > a[u}) or, 

— there is a position p (I < p < u) such that a\p — 1] < x and x < a\p]. 

In the first two cases we put x at the first respectively last position of the array. 
In the third case, we insert x at position p and shift the other elements to the 
right, i.e., a'[i + 1] = a[i] for i > p. We have to take care to cover also the cases 
where the array contains only 1 or 2 elements. As input it will look as follows. 
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Clauses := 




















X case 1 




















CFQRALL i) 




1, 


x <= 


a( 


i) 




> a ' 


(i) = x; 




(FORALL i) 


. x <= 


a 


1), 1 < 


i, 


i 


<= 


u + _1 — > 


a'(i) = a(i - _1) ; 


°/ case 2 




















(FORALL i) 


. i = 


u, 


a(i) 


<= 


X 




> X 


<= a(l) , a' 


(i + _1) = x; 


(FDRALL i) 


. a(u) 


<= 


= x, 1 - 


_1 


< 


= i , 


i < u 










— > X 


<= 


a 


(1), 


a' (i + _1) 


= a(i + 


% case 3 




















(FORALL i) 


. x < 


a(u), 1 


<= 


i , 


i 


< u 


, a(i) < x, 


x <= a(i + _1) 






-> 


a'U 


+ 


-1) 




x; 






(FORALL i) 


. a(l) 


< 


X , X 


< 


a(u), 


1 < 


= i, i < Uj 


x <= a(i) , 




X 


<= 


= a(i 


+ 


_1) 




-> a 


•(i + _1) = 


a(i); 


(FORALL i) 


. a(l) 


< 


X , X 


< 


a(u 


), 


i 


u + _1 — > 


a'(i) = a(i - _1) ; 


(FORALL i) 


. a(l) 


< 


X , X 


< 


a(u 


), 


1 - 


_1 <= i, i 


< u, a(i + _1) < x 






-> 


a'U 


+ 


_1) 




a(i 


+ _D; 




(FORALL i, 




<= 


i > i 


<= 


j. 


j 


<= 


u — > a(i) 


<= a(j); 



with the last clause saying that a was sorted at the beginning. 

There are several things to note. Most importantly, we now have a two-step 
extension. First, an array can be simply seen as a partial function. This gives 
us the first extension % C Ti- To here is the theory of indices (integers, say) 
which we extend by the function a and the axiom for monotonicity of a. Now 
we update a, giving us a second extension Ti 2 T\ where our extension clauses 
Ki are given by the three cases above. 

We need to make sure that the last extension is also local. This is easy to estab- 
lish, because IC2 is a definitional extension or case distinction (cf. [SI07a,SI07b]). 
A definitional extension is one where extension functions / only appear in the 
form ipi(x) —> f(x) — ti{x) with U being a base theory term and the (fi are 
mutually exclusive base theory clauses. This is the reason that we have written 
Mi.i — l,x < a(i) — > a'(i) — x instead of the shorter x < a(l) — > a' (I) = x: 
to ensure that the antecedents of the clauses are all mutually exclusive. Now 
we know that we are dealing with a definitional and therefore local extension. 
(Remember that when assessing whether T2 3 71 is a local extension, 71 is the 
base theory; that T\ is itself an extension is not important at the moment.) 

We need to tell the program that we are dealing with a chain of extensions 
instead of a single one. We do this by declaring to which level of the chain an 
extension function belongs: (f,arity, level). 

In our example that would be 
Extension_functions:={(a' , 1, 2), (a, 1, 1)} 

The program will now automatically determine the level of each extension clause. 
In our example, an extension clause will have level 2 if and only if a' occurs in 
it and level 1 otherwise (level refers to a clause in the base theory). 
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Also recall from the explanations in Section 6 that numerals (names for integers) 
must be preceded by an underscore, and that + and — may be written infix for 
readability; (=, +, — , *, /) are the only functions for which this is allowed 8 . 
Our declarations, therefore should look like this. 

Base_f unctions :={(+, 2) , (-, 2)> 
Extension_functions:={(a' , 1, 2), (a, 1, 1)> 
Relations :={(<=, 2), (<, 2)} 

All that is left to do now is add the proof task - the negation of 
Vi, j. (I < i < j < u + 1 ->■ a'(i) < a'(j)) 



namely: 

l<mAra<nAn<ii+lA -i(a'(m) < a'(m)) 
to the file and hand it over to H-PILoT . The file looks like this. 



Base_f unctions :={(+, 2) , (-, 2)} 




Extension_f unctions :={ Ca' , 1, 2), (a, 1, 1)} 




Relations :={(<=, 2), (<, 2)} 




•/. K 






Clauses := 






X case 1 






CFQRALL i) . 


i = 1, x <= a(i) — > a' (i) = x; 




(FORALL i) . 


x <= a(l), 1 < i, i <= u + _1 — > a'(i) = a(i - 




°/ case 2 






CFQRALL i) . 


i = u, a(i) <= x — > x <= a(l), a' (i + _1) = x; 




(FORALL i) . 


a(u) <= x, 1 - _1 <= i, i < u 






— > x <= a(l), a'(i + _1) = a(i + _1) ; 




% case 3 






(FORALL i) . 


x < a(u) , 1 <= i , i < u, a(i) < x, x <= a(i + 


1) 




— > a' (i + _1) = x; 




(FORALL i) . 


a(l) < x, x < a(u), 1 <= i, i < u, x <= a(i) , 






x <= a(i + _1) — > a'(i + _1) = a(i) ; 




(FORALL i) . 


a(l) < x, x < a(u), i = u + _1 — > a' (i) = a(i 


- _D; 


(FORALL i) . 


a(l) < x, x < a(u), 1 - _1 <= i, i < u, a(i + 


1) < X 




— > a' (i + _1) = a(i + _1) ; 




(FORALL i,j 


. 1 <= i, i <= j , j <= u — > a(i) <= a(j); 




Query := 1 <= 


m ; 




m <= 


n; 




n <= 


u + _1; 




N0T( 


a'(m) <= a'(n) ); 





We do not need to declare a base theory here because we will be using Yices and 
Yices already "knows" integer arithmetic. We call H-PILoT thus: 

hpilot . opt -yices -preprocess ai.loc 

8 When using SPASS, they may also be written infix but nevertheless they are just 
free functions for SPASS. 
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H-PILoT will produce a reduction, put it in a file called ai.ys and pass it over to 
Yices which will say unsat or sat. A note on the flag -preprocess: Establishing 
that some extension is local presupposes that the extension clauses in K, are 
flat and linear. Flatness means that the clauses contain no nesting of extension 
functions. Linearity means that: 

— no variable occurrs twice in any extension term and 

— if any variable occurs in two extension terms, the terms are the same. 

In this example, we have non-flat clauses such as 

(FORALL i) . i = u, a(i) <= x — > x <= a(l) , a' (i + _1) = x; 

We rectify matters by a flattening operation - rewriting the above clause to 

(FORALL i,j). j = i + _1, i = u, a(i) <= x — > 

x <= a(l) , a' (j) = x; 

This will not affect consistency of any proof task w.r.t. JC. However, it does not 
improve readability. Therefore the program will perform flattening/linearization 
only if the option -preprocess is chosen. 

10 Example: Specifying the type information 
10.1 Global constraints 9 

Sometimes we want to restrict the domain of the problem, e.g., we want to 
consider natural numbers instead of integers or we are interested in a real interval 
[a, b] only. Yices and CVC support the definition of subtypes. When using one 
of these it is possible to state a global constraint on the domain of the models 
in the preamble as follows: 

Interval := <= x <= 1; 

This will restrict the domain of the models of the theory to the unit interval 
[0, 1]. It is equivalent to adding the antecedent < x A x < 1, for every variable 
x, to each formula in the clauses and the proof task. 
The bounds of the interval can also be exclusive or mixed as in 

Interval := < x <= 1; 

or one-sided as in 

Interval := 2 <= x; 

9 This feature is not supported for Z3. 



22 



Carsten Thiemann and Viorica Sofronie-Stokkcrmans 



Consider the following example, taken from [SI07a,SI07b], concerning multiple- 
valued logic. The class M.V of all MV-algebras is the quasi-variety generated 
by the real unit interval [0,1] with the Lukasiewicz connectives {V,A,o,=>}, 
i.e., the algebra [0, 1]^ = ([0, 1], V, A, o, =>). The Lukasiewicz connectives can be 
defined in terms of the real functions '+','—' and the relation '<', giving us a 
local extension over the real unit interval. 
Therefore, the following are equivalent: 

(1) MV h Vx Ati s t (x) = U{x) -> s{x) = t(x) 

(2) [o, i] L h Vx Ar=i = - 

(3) To U Def L A Ar=i *i(c) = U(c) As(c)/ i(c) ^J., 

where % consists of the real unit interval [0, 1] with the operations +, — and 
predicate symbol <. 

For instance, we might want to establish whether linearity (x =>■ y) V (y => x) = 1 
follows from the axioms. As an input file for H-PILoT it looks like this. 



Base_f unctions :={(+, 2), (-, 2)} 
Extension_functions:={(V, 1), CM, 1), Co, 1) , 
Relations :={(<=, 2), C<, 2), (>, 2), (>=, 2)} 


(r, 1)} 


Interval 


:= <= x <= 1; 






•/. K 

Clauses 


= % definition of 
(F0RALL x,y) . x 
(F0RALL x,y) . x 


\/ 

<= y — > V(x, y) = 
> y — > V(x, y) = 


y; 

x ; 




X definition of 
CFQRALL x,y) . x 
(F0RALL x,y) . x 


A 

<= y — > M(x, y) = 
> y — > M(x, y) = 


x ; 

y; 




X definition of 
(F0RALL x,y) . x 
(F0RALL x,y) . x 




+ y < _1 — > o(x, 
+ y >= _1 — > o(x, 


y) = _0; 

y) = (x + y) - _1; 




X definition of 
(F0RALL x,y) . x 
(F0RALL x,y) . x 


=> 

<= y — > r(x, y) = 
> y — > r(x, y) = 


_1; 

(_1 - x) + y; 


query := 


7, linearity: x => y . \/ . y => x = 
N0T(V(r(a, b) , r(b, a)) = _1) ; 


L 



10.2 Using standard types 

In default mode using SPASS, H-PILoT hands over a set of general first-order 
formulas without types. However, H-PILoT also provides support for the stan- 
dard types int , real, bool and for free types. When using CVC or Yices the 
default type is int, for Redlog it is real. The default type does not need to be 
specified in the input file. One can also use the -real flag to set the default type 
to real for Yices and CVC. 

Free types are specified as free#i, i = 1,2,... or simply as free if there is 
only one free type. When using free types the flag -f reeType must be set. Only 
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Yices and CVC are able to handle free types (Yices is default when the flag is 
set). When using mixed type in one input file, the types of the functions and 
the constants need to be declared. If the domain of a function is the same as the 
range it is enough to specify the domain as in 

{f oo, arity, level, domainType) 

if they differ say 

{foo, arity, level, domainType, rangeType). 
Constants are simply declared as 
{name, type). 

The following example is taken from [Sof06b] . 



7 Pointers 

7, status unsatisf iable 
Base_functions :={(+, 2) , (-, 2)} 

Extension_f unctions :={ (next , 1, 1, free#l) , Cprev, 1, 1, f ree#l) , 
(priority, 1, 1, free#l, real), 
(state, 1, 1, free#l, free#2)} 

Relations :={(>=, 2)} 

Constants :={ (null, free#l) , (eps, real), (a, f ree#l) , (b, free#l) , 
(RUN, f ree#2) , (WAIT, f ree#2) , (IDLE, free#2)} 

7. K 

Clauses := 

(FORALL x) . OR(state(x) = RUN, state(x) = WAIT, state(x) = IDLE); 
% prev and next are inverse 

(FORALL p) . 0R(p = null, prev(next (p) ) = null, prev(next (p) ) = p) ; 
(FORALL p) . — > p = null, next (prev (p) ) = null, next (prev (p) ) = p; 
(FORALL p, q) . next(q) = next(p) — > p = null, q = null, p = q; 
(FORALL p, q) . prev(q) = prev(p) — > p = null, q = null, p = q; 
(FORALL p) . — > p = null, next(p) = null, state(p) = IDLE, 

state (next (p) ) = IDLE, state (p) = state (next (p) ) ; 
(FORALL p) . OR(p = null, next(p) = null, NOT(state(p) = RUN), 
priority(p) >= priority (next (p) )) ; 



Query := NOT(eps = _5) ; 

N0T(eps = _6) ; 
priority(a) = _5; 
priority(b) = _6; 
a = prev(b) ; 
state (a) = RUN; 
NOT(next(a) = null); 
NOT (a = null) ; 
NOT(b = null) ; 



11 Example: Handling data structures 
11.1 Arrays 

We consider the local fragment of the theory of arrays in more detail and show 
how it can be dealt with by H-PILoT. For the array property fragment ([BMS06]) 
the following syntactical restrictions are imposed. Let A be a set of function 
symbols used for denoting arrays. 
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(1) An index guard is a positive Boolean combination of atoms of the form 
t < u or t = u where t and u are either a variable or a ground term of linear 
arithmetic. 

(2) A value restriction is a formula tpv(c 7 x) containing constants among those 
in c = ci , . . . , Ck and free variables among those 111 X — X ^ ^ * • * ) & n i 

with the 

property that: 

(1) all occurrences of the variables are shielded by function symbols in A; 

(2) no nested array reads are allowed 

i.e., the free variables X{ occur in ipv only in direct array reads a[xi}. 

(3) A universal formula of the form (Vir)((/?/(x) — > (pv{x)) is an array property 
if it is flat, is an index guard and 4>v a value restriction. 

In this section we only consider extensions by clauses of the above form. Our 
base theory is the disjoint, many-sorted combination of linear integer arithmetic 
(Presburger) with a theory of elements. The extension functions are in this case 
the function symbols in A, used for denoting arrays. In order to be able to 
handle this fragment we have to use a particular type of locality, namely minimal 
locality. To use this feature we call H-PILoT with parameter -arrays: 

hpilot.opt -arrays k.loc 

Consider the example of inserting a new element into a sorted array a. Arrays 
are modeled as free functions and array updates are dealt with by introducing 
new array names. In this fashion, let d be identical to a except for position k 
at which it takes value w and let e be identical to d except possibly at position 
/ where we have written x and similarly for c, b and a. The set K, of extension 
clauses we consider is: 



JC 



Our proof task (with additional constraints) is 

w < x < y < 
< k < I < n 
fc + 3 < / 

c[i] = x - a 

b[k] = w 
e[l] = z 
d[k] = y. 

The input file looks as follows. (The operators are written prefix here which 
requires the names plus and minus, because + and - are reserved for infix.) 



(Vi,j)(0<i<j 


< n - 1 -> c[i] < c[j}) 


(1)1 


(Vi,j)(0<i<j 


< n - 1 -> e[i\ < e{j\) 


(2) 


(Vi)(i ^ I -> b[i] 


= c[i]) 


(3) 


(Vz) (z 7^ k — > a[i 


= &[»]) 


(4) ( 


(Vi)(i ^ I -> d[i] 


= e[i]) 


(5) 


(Vz) (z k — > a[i 


= d\i]). 


(6) J 
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'/, Arrays for minimal 


locality 




Base_f unctions : ={ (plus , 2) , 


(minus, 2)> 




Extension_f unctions : — 


{(a, 1), (b, 1), (c, 1), 


(d, 1), (e, 1)} 


rteiations . —\ , zj j 
















Clauses :- (.rUKALL 1, 


3> ■ -0 


<— i , i <— j , 








j <= minusCn, _1) 


— > c(i) <= c(j); 


CFQRALL i, 


j). _0 


<= i, i <= j, 








j <= minusCn, _1) 


— > e(i) <= e(j); 


CFQRALL i) 


— > 


i=l, b(i) = c(i); 




CFQRALL i) 


. — > 


i=k, a(i) = b(i) ; 




(FORALL i) 


. — > 


i=l, d(i) = e(i); 




CFQRALL i) 


. — > 


i=k, a(i) = d(i) ; 




Query := plus(w, _1) 


<= x; 






plus(x, _1) 


<= y; 






plusCy, _1) 


<= z; 






plus(_0, _1) 


<= k; 






plus(k, _1) 


<= 1; 






plusCl, _1) 


<= n; 






plus(k, _3) 


<= 1; 






c(l) = x; 








b(k) = w; 








e(l) = z; 








d(k) = y; 









/C does not yet fulfil the syntactic requirements (index guards must be positive!). 
We rewrite /C as follows: We change an expression i =/= I where i is the (universally 
quantified) variable to i<l — l\Jl + l<i. We rewrite it like this because the 
universally quantified variable i must appear unshielded in the index guard. This 
gives us the following set of clauses. 



(Vi,j)(0<i< j<n 


- 1 c[i] < c[j]) 




(Vi, j)(0 <i<j<n 


- 1 -> e[i\ < e\j\) 


(2) 


(Vi)(* < I - 1 ->• b[i] 


= c\i]) 


(3) 


(Vi)(i + 1 < i ->• b[i] 


= c[i\) 


(4) 


< k- 1 -> a[i] 


= b[i\) 


( 5)> 


(Vi)(fc + 1 < i -> a[i] 


= b[i]) 


(6) 


(Vi)(* < I - 1 ->• d[i\ 


= e[i]) 


(7) 


(Vi)(i + 1 < i ->• d[i\ 


= e[i]) 


(8) 


< k- 1 a[i] 


= d[i]) 


(9) 


(Vi)(fc + 1 < i ->■ a[i] 


= d[i]). 


(10) J 



H-PILoT performs this and the following rewrite steps automatically to spare 
the user this tedious labor. Also, JC is not linear, this must also be taken care 
of. H-PILoT carries out all necessary rewrite steps for the user, who can simply 
input the above file to the system. 

Instead of using free functions to specify array updates, H-PILoT allows the 
user to model array updates directly by using a "write" function - for example, 
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write(a, i, x) denotes a new array which is identical to a except (possibly) at 
position i where the value of the new array is set to x. In this way we can specify 
our problem above as: 



% Arrays for minimal locality with 


write 'function. 




Base_f unctions :={ (+ , 2) 


(-, 2)} 






Extension_f unctions :={ Ca, 1)> 






Relations :={(<=, 2)} 










•/. K 










Clauses := 










(FDRALL i, j) . _0 <= i, 


i <= j. j < 


= n - _1 — > 




write(writeCa,k,w) , 


1, x)(i) <= 


writeCwriteCa,k,w) , 1, 


x)(j); 


(FDRALL i, j) . _0 <= i, 


i <= j. j < 


= n - _1 — > 




write(write(a,k,y) , 


1, z)(i) <= 


write(write(a,k,y) , 1, 


zMj); 


Query := w + _1 <= x 










x + _1 <= y 










y + _1 <= z 










_0 + _1 <= k 










k + _1 <= 1 










1 + _1 <= n 










k + _3 <= 1 











As above, H-PILoT will also automatically split on disequations in the an- 
tecedent. Note also that since we assume that indices of arrays are integers, 
it makes no difference whether we write w + _1 or plus(w, _1) in the input 
file. Linear integer arithmetic will be used (Yices is default). 

11.2 Pointers 

The local fragment of the theory of pointers (cf. [MN05,IJSS08,FIJS10]) is also 
implemented in H-PILoT. We consider pointer problems over a two-sorted lan- 
guage, containing one sort pointer and another scalar sort. The scalar sort can 
be concrete e.g. real, or is kept abstract in which case it is written as scalar. 
There are two function types involving pointers, namely pointer — > pointer 
and pointer —5- scalar, where scalar is either a concrete scalar sort (e.g. real) 
or the abstract sort "scalar". 10 The axioms we consider are all of the form 

Vp. £VC 

where p is a set of pointer variables containing all the pointer variables occurring 
in £ V C, £ contains disjunctions of pointer equalities and C is a disjunction of 
scalar constraints (i.e., literals of scalar type). £ VC may also contain free variables 
of scalar type or, equivalently, free scalar constants. 

We require that pointer terms appearing below a function should not be null 
in order to rule out null pointer errors. That is, for all terms /i(/2(- • • fn{p))), 

10 In [FIJS10] we use an extension of H-PILoT which allows several pointer sorts, as well 
as functions of sort pi,. . .p n —> p (where pt,p are pointer sorts) and pi,... ,p m — > 
scalar. This aspect is discussed at the end of this section. 
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i = l,..,n, occurring in the axiom, the axiom also contains the disjunction 
p = null V f n (p) = null V • • • V / 2 (. . . f n (p)) = null. 

Pointer/scalar formulas complying with this restriction are called nullable. The 
locality result in [IJSS08] allows the integration of pointer reasoning with the 
above features into H-PILoT. We now present an example given in [MN05] , which 
looks like this as input for H-PILoT. (We have added an appropriate proof task.) 



Base_f unctions :={(+, 2) , (-, 2)} 

Extension_f unctions :={ (next , 1, 1, pointer), 
Cprev, 1, 1, pointer), 
(priority, 1, 1, pointer, real)} 

Relations :={(>=, 2)} 

Constants :={ (a, pointer), Cb, pointer)} 

Clauses := 

CFORALL p) . prev(next(p)) = p; 

CFDRALL p) . — > next(prev(p)) = p; 

CFDRALL p) . — > q = null, priority(p) >= priorityCnext(p)) ; 

Query := priority (a) = _5; 

priorityCb) = _6; 
a = prev(b) ; 
NOT (a = null) ; 
NOT (b = null) ; 



H-PILoT can be called without any parameters because the keyword pointer 
is present. This will trigger H-PILoT's pointer mode so that it will add all the 
nullable terms to the axioms and use the specific (stable) locality required. 

Because the scalar type is concrete here (real), H-PILoT will use Yices as the 
back-end prover (its default for arithmetic). If we want to leave the scalar type 
abstract we could write something like 



°/ psiPointers . scalar . loc 
Base_f unctions : ={} 

Extension_f unctions :={ (next , 1, 1, pointer), 
Cprev, 1, 1, pointer), 
(priority, 1, 1, pointer, scalar)} 

Relations :={} 

Constants :={ (a, pointer), (b, pointer), Cc5, scalar), Cc6, scalar)} 

Clauses := (FORALL p) . prevCnext(p)) = p; 

(FORALL p) . next Cprev (p)) = p; 

(FORALL p) . NOT (priority (p) = priority (next (p) )) ; 



Query := priority (a) = c5; 

priorityCb) = c6; 
a = prev(b) ; 
c5 = c6; 
NOT (a = null) ; 
NOTCb = null) ; 



We again can simply type 

hpilot.opt -preprocess psiPointers . scalar . loc 
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without any parameters. H-PILoT will recognize this as a pointer problem and 
use Yices as default, this time because of the free type scalar. There can also be 
more than one pointer type and pointer extensions can be fused with other types 
of extensions in a hierarchy. However, due to the different types of locality that 
need to be employed, the user must specify which levels are pointer extensions. 
He does this by using the keyword Stable. 

For example, the header of a more complicated verification task which mixes 
different pointer types might look like this. 



Base_f unctions :={(-, 2), (+, 2)} 
Extension_f unctions : = 
{ X level 4 

(next', 1,4, pointer#2 ,pointer#2) , Cpos ' , 1 , 4 ,pointer#2 ,real) 
•/. level 3 

(next , 1 ,3 , point er#2 , point er#2) , Cpos , 1 , 3 , point er#2 , real) , 
Cspd, 1 , 3, point er#2 , real) , Csegm, 1 , 3 , point er#2 , point er#l) , 
X level 2 

(bd, 1,2, real, real) , 
•/, level 1 

Clmax ,1,1 ,pointer#l , real) , (length, 1 , 1 , point er#l ,real) , 
Cnexts , 1 , 1 , point er#l , point er#l) , (alloc , 1 , 1 , point er#l , int)} 

Relations :={(<=, 2), (>=, 2), (>, 2), (<, 2)} 

Constants := {(t3,pointer#2) , (t2,pointer#2) , (tl ,pointer#2) , 

(d.real), (StateO , int) , (s ,pointer#l) , (Statel , int)} 

Stable := 1, 3; 



Note that the type pointer#2 must be declared with a higher level than pointer#l 
because pointer#2 refers to pointer#l but not vice versa. 

12 Example: Using the built-in CNF translator 

H-PILoT also provides a clausifier for ease of use. First-order formulas can be 
given as input and H-PILoT translates them into clausal normal form (CNF). 
The CNF-translator does not provide the full functionality of FLOTTER. It 
uses structural formula renaming ([PG86]) and standard Skolemization, not the 
more exotic variants thereof (cf. [NW01]). Nevertheless, it is powerful enough 
for most applications. As a simple example consider the following. 



X cnf.fol 

Base_functions:={ (delta, 2), (abs, 1), (-, 2)} 
Extension_f unctions :={ (f , 1)} 
Relations :={} 



Formulas := 

(FQRALL eps, a, x) . (_0 < eps — > 
AND( _0 < delta(eps, a), 

(abs(x - a) < delta(eps, a) 

— > abs(f(x) - i (a)) < eps))); 

query := 
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H-PILoT translates Formulas to clause normal form. To see the output, we use 

hpilot . opt -preprocess -prClauses cnf.fol 
We obtain the following output file: 



!- Adding formula: 

CFQRALL eps, a, x) . 
(_0 < eps — > 

ANDC _0 < deltaCeps, a), (abs(-(x, a)) < deltaCeps, a) 
--> abs(-(f(x), f(a))) < eps))) 
!- add_formulas 
!- We have 1 levels. 
! - done 

!- Our base theory is: 
! - empty . 

!- Clausifying formulas... 

!- (FORALL z_l, z_3) . 0R( _0 < delta(z_l, z_3) , NOTCO < z_D) 
!- (FORALL z_l, z_2, z_3) . 

0R( N0T(abs(-(z_2, z_3)) < delta(z_l, z_3)), 

abs(-(f (z_2) , f(z_3))) < z_l, N0T(_0 < z_D) 
! - Yielding 2 new clauses : 

!- [z_l, z_2, z_3] abs(-(z_2, z_3)) < delta(z_l, z_3) , _0 < z_l 
— > abs(-(f (z_2) , f(z_3))) < z_l 

!- [z_l, z_3] _0 < z_l > _0 < delta(z_l, z_3) 

!- After rewriting we have as clauses K: 

!- [z_l, z_2, z_3] abs(-(z_2, z_3)) < delta(z_l, z_3) , _0 < z_l 

— > abs(-(f (z_2) , f(z_3))) < z_l 
!- [z_l, z_3] _0 < z_l > _0 < delta(z_l, z_3) 



telling us that the above formula resulted in two new clauses (in addition to 
those given outright under Clauses), viz. 

Vzi,z 3 . < delta(zi,z 3 ) V -i(0 < z\) 

and 

\/zi,z 2 ,z 3 . ^(abs(z 2 ~ z 3 ) < delta(z x , z z ))\J abs(f(z 2 ) - f(z 3 )) < ziV^(0 < z x ). 
In this case no ground clause resulted and H-PILoT stops. 

13 Extended locality 

For some applications we would like to allow more complicated extension clauses, 
say we want them to be inductive (V3) instead of universal. H-PILoT is also 
able to handle extensions with augmented clauses, i.e., formulas of the form 
\fx.<P(x)\/C(x), where <S> is an arbitrary formula which does not contain extension 
functions and C is a clause which does (cf. [IJSS08]). Consider the following 
example taken from [IJSS08]. 

Suppose there is a parametric number m of processes. The priorities associated 
with the processes (non-negative real numbers) are stored in an array p. The 
states of the process - enabled (1) or disabled (0) - are stored in an array a. At 
each step only the process with maximal priority is enabled, its priority is set 
to x and the priorities of the waiting processes are increased by y. This can be 
expressed by the following set of axioms which we denote as Update(p,p', a, a'). 
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Vi(l < i < m A (Vj(l < j < mAj=£i -> p(i)>p(j))) -» a'(i) = 1) 
Vi(l <i <m A (Vj(l < j < rnAj^i -> p(i)>p(j))) ->■ p'(i)=:r) 
Vi(l < i < m A -i(Vj(l < j < mAj=£i -> p(i)>p(j))) ->■ a'(i)=0) 
Vi(l < i < m A ->(Vj(l < j < mAj^i -> p(i)>p(j))) ->■ p'(«)=P(*)+2/), 

where x and y are parameters. We may need to check whether, given that at the 
beginning the priority list is injective, i.e., formula (lnj)(p) holds: 

( I n j ) ( p ) <j<mAl<j<mAi^j^ p(j)), 

then it remains injective after the update, i.e., check whether 

(lnj)(p)AUpdate(p,p',a,o')A(l < c < mAl < < mAc 7^ dAp'(c) = p'(d)) \= ±. 

We need to deal with alternations of quantifiers in the extension. The extension 
formulas /C are augmented clauses of the form 

Vxi, ...,X n . ($(X1, . . . ,X n ) V C(X1, . . . ,X„)), 

where <?(xi, . . . , x n ) is an arbitrary first- order formula in the base signature with 
free variables xi, . . . ,x n and C{x\, . . . , x n ) is a clause in the extended signature. 
As input for H-PILoT, extended clauses may be either written as Vx. (<£(x) V 
C(x)) or as Vx. (<P(x) -)• C"(x)). The input file for H-PILoT looks as follows. 



7o Updating of priorities o: 


proces 


ses 










°/ File update_AE. loc 














Base_f unctions :={(+, 2) , (- 


2)} 












Extension_functions:={Ca J , 


1, 2, bool) , (a, 


1. 1. 


bool) 


(p', 1, 2, real), (p, 1, 1, real)} 


Relations :={(<=, 2), (<, 2) 


, (>, 2)} 










Constants :={ Cx, real), Cy, 


real)} 












'/. K 

Clauses := 














(FORALL i) . _1 <= i, i <= 


m — > 


3 < 


= p(i) 








(FORALL i) . { AKD(_1 <= i 


i <= m 












CFQRALL j) . (AND(_1 <= 


j. j <= 


m, 


N0T(j 


= i)) 












— > 


p(i) 


> p(j))» 










— > a 


'(i) = 


_1; 


(FORALL i) . { ANDO <= i 


i <= m 












(FORALL j) . (ANDO <= 


j. j <= 


m , 


N0T(j 


= i)) 












— > 


p(i) 


> P(j>) 


)} 










-> p 


'(i) = 


x; 


(FORALL i) . { ANDO <= i 


i <= m 












NOT ((FORALL j,i).(AND(. 


i <= j. 


j <= m, N0T(j 


= i)) 










— > 


p(i) 


> P(j)) 


))} 










— > a 


'(i) = 


_0; 


(FORALL i) . { ANDO <= i 


i <= m 












NOT ((FORALL j).(AND(_l 


<= J. j 


<= 


m, N0T(j = 


i)) 










— > 


p(i) 


> p(j>: 


))} 










— > p 


'(i) = 


p(D + y; 


(FORALL i,j). _1 <= i, i <= m, _1 


<= 


j. j ' 


:= m, 


p(i) = 


P(j) 










— > i 


= 




Query := _1 <= c; 














c <= m; 














_1 <= d; 














d <= m; 














x <= _0; 














y > _0; 














N0T(c=d) ; 














p' (c) = p' (d) ; 
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The curly braces '{', '}' are required to mark the beginning and the end of the 
base formula <P. 

14 System evaluation 

We have used H-PILoT on a variety of local extensions and on chains of local 
extensions. An overview of the tests we made is given below. For these tests, 
we have used Yices as the back-end solver for H-PILoT. We distinguish between 
satisfiable and unsatisfiable problems. 

Unsatisfiable Problems. For simple unsatisfiable problems, there hardly is 
any difference in run-time whether one uses H-PILoT or an SMT-solver directly. 
This is due to the fact that a good SMT-solver uses the heuristic of trying out all 
the occurring ground terms as instantiations of universal quantifiers. For local 
extensions this is always sufficient to derive a contradiction. 
When we consider chains of extensions the picture changes dramatically. On one 
test example - the array insertion of Section 9 which used a chain of two local 
extensions - Yices performed considerably slower than H-PILoT: The original 
problem took Yices over 5 minutes to solve. The hierarchical reduction yielded 
113 clauses of the background theory (integers) which were proved to be unsat- 
isfiable by Yices in a mere 0.07s. 

Satisfiable Problems. For satisfiable problems over local theory extensions, 
H-PILoT always provides the right answer. In local extensions, H-PILoT is a 
decision procedure whereas completeness of other SMT-solvers is not guaranteed. 
In the test runs, Yices either ran out of memory or took more than 6 hours when 
given any of the unreduced problems. This even was the case for small problems, 
e.g., problems over the reals with less than ten clauses. With H-PILoT as a front 
end, Yices solved all the satisfiable problems in less than a second with the single 
exception of monotone functions over posets/distributive lattices. 

14.1 Test runs for H-PILoT 

We analyzed the following examples. The satisfiable variant of a problem carries 
the suffix ".sat" . 

array insert. Insertion of an element into a sorted integer array. This is the ex- 
ample from Section 9. Arrays are definitional extensions here. 

array insert (3). Insertion of an element into a sorted integer array. Arrays are 
definitional extensions here. Alternate version with (implicit) existential quan- 
tifier. 

array insert (linear). Linear version of array insert. 

array insert real. Like array insert but with an array of reals. 

array insert real (linear). Linear version of array insert real. 

update process priorities (V3). Updating of priorities of processes. This is the ex- 
ample from Section 13. We have an V3-clause. 
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listl. Made-up example of integer lists. Some arithmetic is required 

chainl. Simple test for chains of extensions (plus transitivity). 

chain2. Simple test for chains of extensions (plus transitivity and arithmetic). 

double array insert. A sorted array is updated twice. This is the example from 
Section 11.1. It is inside the array property fragment. 

mono. Two monotone functions over integers/reals for SMT solver. 

mono for distributive lattices. R. Two monotone functions over a distributive lat- 
tice. The axioms for a distributive lattice are stated together with the defi- 
nition of a relation R: R(x, y) x A y = x. Monotonicity of / (respectively 
of g) is given in terms of R: R(x, y) — > R(f(x),f(y)). Flag -f reeType must 
be used. 

mono for distributive lattices. Same as mono for distributive lattices. R except that 
no relation R is defined. Monotonicity of the two functions /, g is directly 
given: iAi/ = i-> f(x) A f(y) = f(x). Flag -f reeType must be used. 

mono for poset. Two monotone functions over a poset with poset axioms as in 
Section 9. Same as mono, except the order is modeled by a relation R. 

mono for total order. Same as mono except linearity is an axiom. This makes no 
difference unless SPASS is used. 

own. Simple test for monotone function. 

mvLogic/mvl. The example for MV-algebras from Section 10.1. The Lukasiewicz 

connectives can be defined in terms of the (real) operations +,—,<. Linearity 

is deducible from axioms. 
mvLogic/mv2. Example for MV-algebras. The Lukasiewicz connectives can be 

defined in terms of +,—,<. 
mvLogic/bll. Example for MV-algebras with BL axiom (redundantly) included. 

The Lukasiewicz connectives can be defined in terms of +, — , <. 
mvLogic/example_6.1. Example for MV-algebras with monotone and bounded 

function. The Lukasiewicz connectives can be defined in terms of +, — , <. 
RBC_simple. Example with train controller. 
RBC_variable2. Example with train controller. 

14.2 Test results 

The running times are given in User + sys times (in s). Run on an Intel Xcon 
3 GHz, 512 kB cache; median of 100 runs (entries marked with 1 : 10 runs; 
marked with 2 : 3 runs). The third column lists the number of clauses produced; 
"unknown" means Yices answer was unknown, "out. mem." means out of memory 
and time out was set at 6h. Yices version 1.0.19 was used. 

The answer "unknown*" for the satisfiable examples with monotone functions 
over distributive lattices/posets (H-PILoT followed by Yices) is due to the fact 
that Yices cannot handle the universal axioms of distributive lattices/posets. A 
translation of such problems to SAT provides a decision procedure (cf. [Sof05] 
and also [Sof03]). 
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Name 


status 


#cl. 


H-PILoT 

+ yices 


H-PILoT 

+ yices 

stop at K\G\ 


yices 


array insert (implicit 3) 


Unsat 


310 


0.29 


0.06 


0.36 


array insert (implicit 3). sat 


Sat 


196 


0.13 


0.04 


time out 


array insert 


Unsat 


113 


0.07 


0.03 


318. 22 1 


array insert (linear version) 


Unsat 


113 


0.07 


0.03 


7970. 53 x 


array insert. sat 


Sat 


111 


0.07 


0.03 


time out 


array insert real 


Unsat 


113 


0.07 


0.03 


360.00 1 


array insert real (linear) 


Unsat 


113 


0.07 


0.03 


7930.00 x 


array insert real. sat 


Sat 


111 


0.07 


0.03 


time out 


update process priorities 


Unsat 


45 


0.02 


0.02 


0.03 


update process priorities. sat 


Sat 


37 


0.02 


0.02 


unknown 


listl 


Unsat 


18 


0.02 


0.01 


0.02 


list 1. sat 


Sat 


16 


0.02 


0.01 


unknown 


chain 1 


Unsat 


22 


0.01 


0.01 


0.02 


chain2 


Unsat 


46 


0.02 


0.02 


0.02 


mono 


Unsat 


20 


0.01 


0.01 


0.01 


mono. sat 


Sat 


20 


0.01 


0.01 


unknown 


mono for distributive lattices. R 


Unsat 


27 


0.22 


0.06 


0.03 


mono for distributive lattices. R. sat 


Sat 


26 


unknown* 


unknown* 


unknown 


mono for distributive lattices 


Unsat 


17 


0.01 


0.01 


0.02 


mono for distributive lattices. sat 


Sat 


17 


0.01 


0.01 


unknown 


mono for poset 


Unsat 


20 


0.02 


0.02 


0.02 


mono for poset. sat 


Sat 


19 


unknown* 


unknown* 


unknown 


mono for total order 


Unsat 


20 


0.02 


0.02 


0.02 


own 


Unsat 


16 


0.01 


0.01 


0.01 


mvLogic/mvl 


Unsat 


10 


0.01 


0.01 


0.02 


mvLogic/mvl.sat 


Sat 


8 


0.01 


0.01 


unknown 


mvLogic/mv2 


Unsat 


8 


0.01 


0.01 


0.06 


mvLogic/bll 


Unsat 


22 


0.02 


0.01 


0.03 


mvLogic /example_6. 1 


Unsat 


10 


0.01 


0.01 


0.03 


mvLogic /example_6. 1 .sat 


Sat 


10 


0.01 


0.01 


unknown 


RBC_simple 


Unsat 


42 


0.03 


0.02 


0.03 


double array insert 


Unsat 


791 


1.16 


0.20 


0.07 


double array insert 


Sat 


790 


1.10 


0.20 


unknown 


RBC_simple.sat 


Sat 


40 


0.03 


0.02 


out. mem. 


RBC_variable2 


Unsat 


137 


0.08 


0.04 


0.04 


RBC_variable2.sat 


Sat 


136 


0.08 


0.04 


out. mem. 



15 Examples 
15.1 A case study 

In [IJSS08] we used H-PILoT for verifying the correctness of the controller of 
a system of trains moving on a linear track. In [FIJS10], H-PILoT's ability to 
decide the pointer fragment of Section 11.2 has been used in the verification 



34 



Carsten Thiemann and Viorica Sofronie-Stokkcrmans 



of real-time systems which exhibit rich and dynamic data structures. There H- 
PILoT was part of a tool chain employed for the verification of a case study 
from the European Train Control System standard, describing the controller of 
a system of trains moving on a rail track with complex topology - modeled 
using two-sorted pointer structures. The tool chain received as input a high level 
specification and a formula (a safety property), and generated proof obligations, 
which were automatically verified using H-PILoT (with Yices). 
The verification problem we considered are expressed as satisfiability problems 
for universally quantified formulas, hence cannot be solved by SMT-solvers alone. 
The experimental results show H-PILoT to be a very efficient tool for the dis- 
charging of all the proof tasks of the case study. The full type system imple- 
mented in H-PILoT increased the efficiency considerably by blocking unneces- 
sary instantiations. The tool chain used in the case study range from a specifi- 
cation language for real-time systems called COD to the translation of such a 
specification via phase-event automata (Syspect/PEA) to transition constraint 
systems (TCS) which can then be exported to H-PILoT. The invariant for every 
transition in the TCS was checked. 

Since the invariant was too complex to be handled by the clausificr of H-PILoT 
we checked the invariant for every transition in two parts yielding 92 proof 
obligations. Further, we performed tests to ensure that the specifications are 
consistent. The time to compute the TCS from the specification was insignificant. 
The overall time to verify all transition updates with Yices and H-PILoT in the 
unsatisfiable case (when the invariant is correct) does not differ much. There is 
one example - the speed update - on which H-PILoT was 5 times faster than 
Yices alone. 

We also made tests with the verification of a set of conditions which was not 
inductive over all transitions. Here, H-PILoT was able to provide a model after 
8s whereas Yices detected unsatisfiability for 17 problems, returned "unknown" 
for 28, and timed out once. For the consistency check H-PILoT was able to 
provide a model after 3s, whereas Yices answered "unknown" . 
During the development of the case study H-PILoT helped us finding the correct 
transition invariants by providing models for satisfiable sets of clauses (occurring 
when the safety formulae were not invariant under transitions). 

15.2 A run example of H-PILoT 

We consider an example taken from [BM07] (Example 11.10). The input file 
looks as follows. 

7. arrays_from_book. loc 

Base_f unctions :={(+, 2), (-, 2)} 

Extension_f unctions :={ Ca, 1, 1, int , int) , (b, 1, 1, int, int)} 
Relations :={(<=, 2)} 

•/. K 

Formulas := 

AND( (FORALL i) . CAND(1 <= i, i <= u) — > a(i) = b(i)), 
NDT( CFDRALL i) . CANDC1 <= i , i <= u + _1) — > 

writeCa, u + _1, b(u +_l))(i) = Mi)))); 
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The arrays a and b are considered to be equal between the constants I and u. 
We prove that if we update a at u + 1 to b(u + 1) then a and b should be equal 
between I and u + 1. The formula above denies this and should therefore be 
inconsistent. We call H-PILoT with 

hpilot.opt -preprocess -prClauses arrays_f rom_book. loc 

-preprocess is needed as usual; we use -prClauses to get a trace of the pro- 
gram. (Because the array keyword write appears in the input we don't have to 
use the flag -arrays: it is implicit.) The trace looks as follows (to improve read- 
ability we aligned the level labels and often left out the listing of the extension 
ground terms due to space constraints). 
First, H-PILoT reads the input and clausifies the formula. 



Sta: 



ng hpilot**********' 



> a(i) - b(i», 
Cu, _!)) ~ > readfwriteCa 



arrays_f rom_book .loc 
Adding formula: 

AND( (FDRALL i) . (AND ( 1 <= i, i < 
WDT( (FDRALL i) . (AND ( 1 <= i, 

Clausifying formulas... 

(FORALL z_l). DR( N0T(1 <= z_l) , N0T(z_l <= u) , a(z_l) = b(z_l)) 

1 <= sk_l 

ak_l <- + (u, _1) 

WDT(read(write(a, +(u, _1) , b(+(u, sk_l) = b(sk_l)) 

Yielding 4 new clauses: 

read(»rite(a, +(u, _1) , b(+(u, sk_l) - b(sk_l) 

— > sk_l <= +(u, _1) 
— > 1 <= sk_l 

[z_l] 1 <- z_l, z_l <- u — > a(z_l) - b(z_l) 



+(u, _l),b(*(u, _1))), 



Extensii 
Extensii 
Extensii 
Extensii 



ground te; 
ground te: 
ground te: 
ground te: 



b(sk_l) , b(+(u 



H-PILoT then replaces array writes by introducing new arrays: 
write(a, u-\- l,b(u+ 1)) is replaced by: Vi.z ^ u-\- 1 — > a w i(i) = a(i) and a w i(u + 
1) = b(u + 1). To remain in the decidable fragment, H-PILoT replaces Mi.i ^ 
u + 1 — )• a w i(i) = a(i) with Vi.z < u + 1 — 1 — >■ a w \{i) = a(i) and Vi.u + 1 + 1 < 



(i) = a(i). 



Replacing writes... 
We have 1 levels . 
Our base theory is: 
empty . 

Splitting clause [i] > i = +(u, 

terms: on eq i = + (u, _1) 

Checking APF for clause [i] i <= -(+(u 
Extension ground terms: > true 

Checking APF for clause [i] +(+(u, _1) <= i > a_w 

Extension ground terms: > true 

Checking APF for clause [z_l] 1 <= z_i, z_l <= u > a(z 

Extension ground terms: > true 

Recalculating all levels. 



1), a_wl(i) = a(i) 
1), _D > a_ 



i) = a(i) 
i) = a(i) 
) = b(z_l) 



L: 1 
L : 
L : 
L : 1 



H-PILoT then flattens and linearizes the result. 



After rewriting we have as clai 
[i, x_l] x_l = i, i <= -C+Cu, 
[i, x_l] x_l = i, +(+(u, 
[z_l, x_l] x_l = z_l, 1 <= z_ 
and as query: 
— > 1 <= sk_l 
— > sk_l <= +(u, _1) 

a_wl(sk_l) = b(sk_l) > 

— > a_wl(+(u, _1» = bC+Cu, 
Our query G is : 
— > 1 <= sk_l 

> sk_l <= +(u, _1) 

a_wl(sk_l) = b(sk_l) — > 
— > a_ W l(+( U , _1» = bC+Cu, 
End preprocessing 



■ a_wl(i) = 
-> a(z_l) ' 



Extensii 
Extensii 



L: 1; Extension ground 1 
Extension ground terms: 



ground terms : 
ground terms : 
ground terms : 

ground terms : 
ground terms : 
wl(sk_l), b(sk_l) 
., _l»,b(+(i 



L: 0; Extension ground terms: 
L: 0; Extension ground terms: 
L: 1; Extension ground terms: a_wl(sk_l), b(sk_l) 
Extension ground terms: a_wl(+(u, _l)),b(+(u, 



H-PILoT then calculates the set of instances K,^P(G)\ and simplifies the terms 
to avoid redundant instances of clauses (e.g. u+1— 1 is replaced by u). 
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We have 5 index terms for minimal locality 1, sk_l, u, + (u, _1) , +(u, _2) 
K has 3 members . 

[i. x_l] x_l = i, i <= -(+(u, _1) — > a_wl(i) = a(x_l) L: 1 

[i. x_l] x_l = i, +(+(u, _1) <= i — > a_wl(i) = a(x_l) L: 1 

[z_l, x_l] x_l = z_l, 1 <= z_l, z_l <= u — > a(z_l) = b(x_l) L: 1 
Computing K<G>. . . 
K<G> looks as follows: 
K_G has 75 members. 

□ 1 = 1, 1 <= -(+(u, _1) — > a_wl(l) = a(l) L: 
[] 1 = sk_l, sk_l <= -C+(u, _1) — > a_wl(sk_l) = a(l) L: 
[] 1 = u, u <= -(+(u, _1) — > a_wl(u) = a(l) L : 
[] 1 = +(u, + (u, _1) <= -C+(u, _1), _1) — > a_wl(+(u, _D) = a(l) L : 

□ 1 = +(u, _2), + (u, _2) <= -(+(u, _1) — > a_wl(+(ii, _2)) = a(l) L : 

□ sk_l = 1, 1 <= -(+(u, _1) — > a_wl(l) = a(sk„l) L: 0: 

□ sk_l = sk_l, sk_l <= -(+(u, _1) — > a_wl(sk_l) = a(sk_l) L: 

□ sk_l = u, u <= _1) — > a_wl(u) = a(sk„l) L: 
[] sk_l = + (u, + (u, _1) <= -(+(u, _1) — > a_wl(+(u, = a(sk_l) L: 
[] sk_l = + (u, _2) , _2) <= -(+(u, _1), _1) — > a_wl(+(u, _2)) = a(sk_l) L: 
[] u = 1, 1 <= -(+(u, _1) — > a_wl(l) = a(u) L : 
[] u = sk_l, sk_l <= -(+(u, _1), _1) — > a_wl(sk_l) = a(u) L: 
[] u = u, u <= _1) — > a_wl(u) = a(u) L: 

□ u = +(u, + (u, _1) <= -(+(u, _1) — > a_wl(+(u, = a(u) L: 

□ u = +Cu, _2), +(u, _2) <= -(+(u, _1) — > a_wl(+(u, _2)) = a(u) L : 0: 

□ +(u, _D = 1, 1 <= -(+(u, _1) — > a_wl(l) = a(+(u, L: 

□ +(u, _D = sk_l, sk_l <= -(+(u, _1) > a_wl(sk_l) = a(+(u, L: 

□ +(u, _D = u, u <= -(+(u, _1) — > a_wl(u) = a(+(u, L: 

□ +(u, _1) = +(u, + (u, _1) <= -(+(u, _1) > a_wl(+(u, = a(+(u,_l)) L: 

[] +(u, _1) = +(u, _2), + (u, _2) <= -(+(u, _1) > a_wl(+(u, _2)) = a(+(u,_l)) L : 

□ +(u, _2) = 1, 1 <= -(+(u, _1) — > a_wl(l) = a(+(n, _2)) L: 

□ +(u, _2) = sk_l, sk_l <= -(+(u, _1) > a_wl(sk_l) = a(+(u, _2)) L: 

□ +(u, _2) = u, u <= -C+(u, _1) — > a_wl(u) = a(+(n, _2)) L: 

□ +(u, _2) = +(u, + (u, _1) <= -(+(u, _1) > a_wl(+(u, _1)) = a(+(u,_2)) L : 0: 

□ +(u, _2) = + (u, _2), +(u, _2) <= -(+(u, _1) > a_wl(+(u, _2)) = a(+(u,_2)) L : 

□1=1, -K+(u, _1) <= 1 — > a_wl(l) = a(l) L : 

□ 1 = sk_l, +(+(u, _1) <= sk_l — > a_wl(sk_l) = a(l) L: 

□ 1 = u, -K+Oi, _1) <= u — > a_wl(u) = a(l) L : 

□ 1 = +(u, +(+(u, _1) <= +(u, _1) — > a_wl(+(u, _1» = a(l) L: 

□ 1 = +Cu, _2), +(+(u, _1) <= +(u, _2) — > a_wl(+(u, _2)) = a(l) L : 

□ sk_l = 1, +(+(u, _1) <= 1 > a_wl(l) = a(sk_l) L: 

□ sk_l = sk_l, +(+(u, _1) <= sk_l — > a_wl(sk_l) = a(sk_l) L: 

□ sk_l = u, +(+(u, _1) <= u — > a_wl(u) = a(sk„l) L: 0: 
[] sk_l = + (u, _1) <= +(u, _1) — > a_wl(+(u, = a(sk_l) L: 

□ sk_l = + (u, _2) , +(+(u, _1) <= +(u, _2) > a_wl(+(u, _2)) = a(sk_l) L: 

[] u = 1, _1) <= 1 — > a_wl(l) = a(u) L: 

[] u = sk_l, +(+(u, _1) <= sk_l — > a_wl(sk_l) = a(u) L: 

□ u = u, _1) <= u — > a_wl(u) = a(u) L: 

□ u = +(u, +(+(u, _1) <= +(u, _1) — > a_wl(+(u, = a(u) L : 
[] u = +(u, _2), +(+(u, _1) <= +(u, _2) — > a_wl(+(u, _2)) = a(u) L: 

□ +(u, _1) = 1, +(+(u, _1) <= 1 — > a_wl(l) = a(+(u, L: 

□ +(u, _D = sk_l, +(+(u, _1) <= sk_l > a_wl(sk_l) = a(+(u, L: 0: 

□ +(u, _1) = u, +(+(u, _1) <= u — > a_wl(u) = a(+(n, L: 

□ +(u, _1) = +(u, +(+(u, _1) <= +(u, _1) > a_wl(+(u, = a(+(u,_l)) L : 

□ +(u, _1) = +(u, _2), +(+(u, _1) <= +(u, _2) > a_wl(+(u, _2)) = a(+(u,_l)) L : 

[] +(u, _2) = 1, +(+(u, _1) <= 1 — > a_wl(l) = a(+(n, _2)) L: 

□ +(u, _2) = sk_l, _1) <= sk_l > a_wl(sk_l) = a(+(u, _2)) L: 

□ +(u, _2) = u, +(+(u, _1) <= u — > a_wl(u) = a(+(n, _2)) L: 

□ +(u, _2) = +(u, +(+(u, _1) <= +(u, _1) > a_wl(+(u, _1>) = a(+(u,_2)) L : 

□ +(u, _2) = +(u, _2), +(+(u, _1) <= +(u, _2) > a_wl(+(u, _2)) = a(+(u,_2)) L: 

□ 1 = 1, 1 <= 1, 1 <= u > a(l) = b(l) L: 0: 

□ sk_l = 1, 1 <= 1, 1 <= u > a(l) = b(sk_l) L: 

[] u = 1, 1 <= 1, 1 <= u > a(l) = b(u) L: 

□ +(u, _D = 1, 1 <= 1, 1 <= u — > a(l) = b(+(u, _1)) L: 

□ +(u, _2) = 1, 1 <= 1, 1 <= u — > a(l) = b(+(u, _2)) L: 

□ 1 = sk_l, 1 <= sk_l, sk_l <= u — > a(sk_l) = b(l) L: 

□ sk_l = sk„l, 1 <= sk_l, sk_l <= u — > a(sk_l) = b(sk_l) L: 
[] u = sk_l, 1 <= sk_l, sk_l <= u — > a(sk_l) = b(u) L: 
[] +(u, _D = sk_l, 1 <= sk_l, sk_l <= u — > a(sk_l) = b(+(u, L: 0: 

□ +(u, _2) = sk_l, 1 <= sk_l, sk_l <= u — > a(sk_l) = b(+(u, _2)) L: 
[] 1 = u, 1 <= u, u <= u > a(u) = b(l) L : 

□ sk_l = u, 1 <= u, u <= u —> a(u) = b(sk_l) L: 
[] u = u, 1 <= u, u <= u > a(u) = b(u) L: 

□ +(u, _D = u, 1 <= u, u <= u — > a(u) = b(+(u, L : 0: 

□ +(u, _2) = u, 1 <= u, u <= u — > a(u) = b(+(u, _2)) L: 

□ 1 = +(u, 1 <= +(u, +(u, _1) <= u — > a(+(u, = b(l) L: 

□ sk_l = 1 <= +(u, +(u, _1) <= u —> a(+(u, _1)) = b(sk_l) L: 
[] u = +(u, 1 <= +( u , +(u, _1) <= u — > a(+(u, = b(u) L: 0: 

□ +(u, _D = +(u, 1 <= +(u, +(u, _1) <= u > a(+(u, = b(+(u,_l)) L: 0: 

□ +(u, _2) = +(u, 1 <= +(u, +(u, _1) <= u > a(+(u, = b(+(u,_2)) L : 

□ 1 = +(u, _2), 1 <= +( u , _2), +(u, _2) <= u — > a(+(u, _2)) = b(l) L: 

□ sk_l = +(u, _2), 1 <= _2), +(u, _2) <= u > a(+(u, _2)) = b(sk_l) L: 

[] u = +Cu, _2), 1 <= +(u, _2), +(u, _2) <= u — > a(+(u, _2)) = b(u) L: 

□ +(u, _D = +(u, _2), 1 <= +(u, _2), +(u, _2) <= u — > a(+(u, _2)) = b(+(u,_l)) L: 

□ +(u, _2) = +(u, _2), 1 <= +(u, _2), +(u, _2) <= u > a(+(u, _2)) = b(+(u,_2)) L : 



The result is then purified: 



computing def s . . . 
We have the following definitions: 
> e_l = a(l) 



L: 0; Extension ground terms: a(l) 
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2 = a<sk_l) 


L: 


0; 




ground terms 


a(sk_l) 






3 = a(u) 


L: 


0; 


Extension 


ground terms 


a(u) 


— > 




4 = aC+Cu, _D) 


L: 


0; 


Extension 


ground terms 


a(+(u, 


— > 




5 = af+Cu, _2)) 


L: 


0; 


Extension 


ground terms 


aC+Cu, _2)) 






6 = a_wl(l) 


L: 


0; 


Extension 


ground terms 


a_wl(l) 






7 = a_wl(sk_l) 


L: 


0; 


Extension 


ground terms 


a_wl(sk_l) 






S = a_wl(u) 


L: 


0; 


Extension 


ground terms 


a.wl(u) 






9 = a_wl(+(u, 


L: 


0; 


Extension 


ground terms 


a_wl(+(u, 


— > 




10 = a_wl(+(u, _2)) 


L: 


0; 


Extension 


ground terms 


a_wl(+(u, _2)) 






11 = b(l) 


L: 


0; 


Extension 


ground terms 


bCD 


— > 




12 = b(sk_l) 


L: 


0; 


Extension 


ground terms 


b(sk_l) 






13 = b(u) 


L: 


0; 


Extension 


ground terms 


b(u) 






14 = b(+(u, _1)) 


L: 


0; 


Extension 


ground terms 


bC+Cu, 






15 = b(+(u, _2)) 


L: 


0; 


Extension 


ground terms 


bC+Cu, _2)) 



Pur if ii 



K_G has 75 members. 



1 = 1, 1 


<= -C+Cu, _1), _1) — > e_6 = e_l 












erms 


1 = sk_l 


sk_l <= -(+(u, _1), _1) — > e_7 = e_l 




L: 





Extension 


S round 




1 = u, u 


<= -(+(u, _1), _1) — > e_8 = e_l 










S round 




1 = + (u, 


_D, +(u, _1) <= -(+(u, _1), _1) — > e_9 = e_l 




L- 




Extension 




terms 


1 = +Cu, 


_2), +(u, _2) <= -(+(u, _1), _1) — > e_10 = e_l 




L \ 




Extension 




terms 


sk_l = 1 


1 <= -(+(u, _1) , _1) > e_6 = e_2 




L " 




Extension 




terms 


sk_l = sk_l, sk_l <= -(+(u, _1), _1) — -> e_7 = e_2 




L ) 




Extension 


S round 


terms 


sk_l = u 


u <= -C+(u, _1), _1) > e_8 = e_2 




L: 


o 


Extension 


S round 






u, _1), + (u, _1) <= -(+(u, _1), _1) > e_9 = e_2 


L: 


o 


Extension 


S round 




sk_l = + 


u, _2), + (u, _2) <= -C+(u, _1), _1) > e_10 = e 


2 


L: 


o 


Extension 


S round 




u = 1, 1 


<= -(+(u, _1) — > e_6 = e_3 




L: 


o 


Extension 






u = sk_l 


sk_l <= -(+(u, _1) — > e_7 = e_3 




L: 


o 


Extension 


round 


terms 




<= -C+Cu, _D, _D — > e_8 = e_3 




L: 


o 








u = + (u, 


_D, +(u, _1) <= -(+(u, _1), _1) — > e_9 = e_3 




L: 


o 


Extension 




terms 


u = +(u, 


_2), +(u, _2) <= -C+Cu, _1), _1) — > e_10 = e_3 




L: 


o 


Extension 


d 




+(u, _1) 


= 1, 1 <= -(+(11, _1), _1) — > e_6 = e_4 




L: 


o 


Extension 


round 


terms 


+(u, _1) 


= sk_l, sk_l <= -(+(u, _1), _1) — > e_7 = e_4 




L: 


o 


Extension 






+(u, _1) 


= u, u <= -C+(u, _1), _1) — > e_8 = e_4 




L: 


o 


Extension 


round 


terms 


+(u, _1) 


= +(u, _1), +(u, _1) <= -(+(u, _1), _1) > e.9 


e_4 


L: 


o 


Extension 






+(u, _1) 


= +(u, _2), +(u, _2) <= -(+(u, _1), _1) > e_10 


= e_4 








d 


terms 


+(u, _2) 


= 1, 1 <= -(+(11, _1), _1) — > e_6 = e_5 




L- 




Extension 




terms 


+(u, _2) 


= sk_l, sk_l <= -(+(u, _1), _1) — -> e_7 = e_5 




L \ 





Extension 




terms 


+(u, _2) 


= u, u <= -(+(u, _1), _1) — > e_8 = e_5 




L \ 




Extension 


groun 


terms 


+(u, _2) 


= +(u, _1), +(u, _1) <= -(+(u, _1), _1) > e_9 


e_5 


L \ 


. 


Extension 




terms 


+(u, _2) 


= +(u, _2), +(u, _2) <= -(+(u, _1), _1) > e_10 


= e_5 


L ' m 





Extension 




terms 


1 = 1,+ 


+ (u, _D , _D <= 1 — > e_6 = e_l 




L ' 





Extension 




terms 


1 = sk_l 


+C+Cu, _1) <= sk_l — > e_7 = e_l 




L * 





Extension 


groun 


terms 


1 = u, + 


+(u, _1) , _1) <= u — > e_8 = e_l 




l ; 





Extension 


SrOUn 


terms 


1 = +Cu, 


.1), +(+(u, _1) <= +(u, _1) — > e_9 = e_l 




L \ 




Extension 




terms 


1 = +(u, 


_2), +(+(u, _1) <= +(u, _2) — > e_10 = e_l 




L \ 





Extension 




terms 


sk_l = 1 


+(+(u, _1), _1) <= 1 > e_6 = e_2 




L ' 





Extension 




terms 


sk_l = s 


_1, +(+(u, _1), _1) <= sk_l — > e_7 = e_2 




L ) 





Extension 




terms 


sk_l = u 


+(+(u, _1) <= u > e^8 = e_2 




L ' 





Extension 




terms 


sk_l = + 


u, _1), +(+(u, _1), _1) <= +(u, _1) > e_9 = e_2 


L: 


o 


Extension 


d 


terms 


sk_l = + 


u, _2), +(+(u, _1), _1) <= +(u, _2) — > e_10 = e 


2 


L: 


o 


Extension 




terms 


u = 1, + 


+(u, _1) <= 1 — > e_6 = e_3 




L: 


o 




d 


terms 


u = sk_l 


+C+Cu, _1) <= sk_l — > e_7 = e_3 




L: 


o 


Extension 


ground 


terms 




+(u, _1) <= u — > e_8 = e_3 




L: 





Extension 


ground 


terms 


u = +(u, 


_D, +(+(u, _1) <= +(u, ,1) — > e_9 = e_3 




L: 





Extension 


ground 


terms 


u = +(u, 


_2), +(+(u, _1) <= +(u, _2) — > e_10 = e_3 




L: 





Extension 


ground 


terms 


+(«. -1) 


= 1, +(+(u, _1) <= 1 — > e_6 = e_4 




L: 





Extension 


ground 


terms 


+ (u, _1) 


= sk_l, +(+(u, _1), _1) <= sk_l > e_7 = e_4 




L: 





Extension 


ground 




+(«. -1) 


= u, +(+(u, _1) <= u — > e_8 = e_4 




L: 





Extension 


ground 


terms 


+ (u, _1) 


= +(u, _1), +(+(u, _1), _1) <= +(u, _1) > e_9 


e_4 


L: 





Extension 


ground 




+(«. -1) 


= +(u, _2), +(+(u, _1) <= +(u, _2) > e_10 


= e_4 


L: 





Extension 


ground 


terms 


+ (u, _2) 


= 1, +(+(u, _1) <= 1 — > e_6 = e_5 




L: 





Extension 


ground 




+(«. -2) 


= sk_l, +(+(u, _1) <= sk_l > e_7 = e_5 




L: 





Extension 


ground 


terms 


+(u, _2) 


= u, +(+(u, _1) <= u — > e_8 = e_5 




L: 





Extension 


ground 


terms 


+(«. -2) 


= +(u, +(+(u, _1) <= +(u, _1) > e_9 


e_5 


L: 





Extension 


ground 


terms 


+(u, _2) 


= +(u, _2), +(+(u, _1), _1) <= +(u, _2) > e_10 


= e_5 


L: 





Extension 


ground 




1 = 1, 1 


<= 1, 1 <= u > e_l = e_ll 




L: 





Extension 


ground 


terms 


sk_l = 1 


1 <= 1, 1 <= u > e_l = e_12 




L: 





Extension 


ground 




u = 1, 1 


<= 1, 1 <= u > e_l = e_13 




L: 





Extension 


ground 


terms 


+ (u, _1) 


= 1, 1 <= 1, 1 <= u — > e_l = e_14 




L: 





Extension 


ground 




+(«. -2) 


= 1, 1 <= 1, 1 <= u — > e_l = e^l5 




L: 





Extension 


ground 


terms 


1 = sk_l 


1 <= sk_l, sk_l <= u — > e_2 = e_ll 




L: 





Extension 


ground 




sk_l = sk_l, 1 <= sk_l, sk_l <= u > e_2 = e_12 




L: 





Extension 


ground 


terms 


u = sk_l 


1 <= sk_l, sk_l <= u > e_2 = e_13 




L: 





Extension 


ground 


terms 


+(u, .1) 


= sk_l, 1 <= sk_l, sk_l <= u — > e_2 = e_14 




L: 





Extension 


ground 




+ (u, _2) 


= sk_l, 1 <= sk_l, sk_l <= u — > e_2 = e_15 




L: 





Extension 


ground 


terms 


1 = u, 1 


<= u, u <= u > e_3 = e_ll 




L: 





Extension 


ground 


terms 


sk_l = u 


1 <= u, u <= u — > e_3 = e_12 




L: 





Extension 


ground 




u = u, 1 


<= u, u <= u > e_3 = e_13 




L: 





Extension 


ground 




+ (u, _1) 


= u, 1 <= u, u <= u — > e_3 = e_14 




L: 





Extension 


ground 




+(«. -2) 


= u, 1 <= u, u <= u — > e_3 = e_15 




L: 





Extension 


ground 


terms 


1 = +(u, 


_1), 1 <= +(u, _1), +(u, _1) <= u — > e_4 = e_ll 




L: 





Extension 


ground 




sk_l = +(u, _1), 1 <= +(u, _1), +(u, _1) <= u > e_4 = e 


12 


L: 





Extension 


ground 


terms 




_1), 1 <= + (u, _1), +(u, _1) <= u — > e_4 = e_13 




L: 





Extension 


ground 




+(u, _1) 


= + (u, _1), 1 <= +(u, _1), +(u, _1) <= u > e_4 


= e_14 


L: 





Extension 


ground 


terms 


+ (u, _2) 


= + (u, _1), 1 <= +(u, _1), +(u, _1) <= u — > e_4 


= e_15 


L: 





Extension 


ground 




1 = +(u, 


_2), 1 <= +(u, _2), +(u, _2) <= u > e_5 = e_ll 




L: 





Extension 


ground 


terms 


sk_l = + 


u, _2), 1 <= +(u, _2), +(u, _2) <= u — > e_5 = e 


12 


L: 





Extension 


ground 






_2) , 1 <= +(u, _2), +(u, _2) <= u > e_5 = e_13 




L: 





Extension 


ground 




+(u, _1) 


= + (u, _2), 1 <= +(u, _2), +(u, _2) <= u — > e_5 


= e_14 


L: 





Extension 


ground 
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□ +(u, _2) - ♦ (_, _2), 1 <- 
— > 1 <= sk_l 
— > sk_l <= + (u, _1) 



(u, _2), + (u, 



L: 


0; 


Extensio 


n ground terms : 


L: 


0; 


Extensio 


n ground terms : 


L: 


0; 


Extensio 


n ground terms : 


L: 


0; 


Extensio 


n ground terms : 


L: 


0; 


Extensio 


n ground terms : 



The introduced definitions are replaced by the corresponding congruence axioms. 



Replacing D by NO: 
This yields 30 clauses. 



+(u, _1) 


= +(u, _2) > e_14 = e_15 


L 





Extensio 


l ground terms 




_2) > e_13 = e_15 


L 





Extensio 


l ground terms 




_1) — > e_13 = e_14 


L 





Extensio 


l ground terms 


sk_l = + 


u, _2) > e_12 = e_15 


L 





Extensio 


l ground terms 


sk_l = + 


u, _D > e_12 = e_14 


L 





Extensio 


l ground terms 


sk_l = u 


— > e^.12 = e_13 


L 





Extensio 


l ground terms 


1 = +(u, 


_2) — > B_ll = e_15 


L 





Extensio 


l ground terms 


1 = +(u, 


_1) — > e_ll = e_14 


L 





Extensio 


l ground terms 


1 = u — 


> e_ll = e_13 


L 





Extensio 


l ground terms 


1 = sk_l 


— > e_.ll = e_12 


L 





Extensio 


l ground terms 


+(u, _1) 


= +(u, _2) — > e_9 = e_10 


L 





Extensio 


l ground terms 




_2) > e_8 = e_10 


L 





Extensio 


l ground terms 




_1) — > e_8 = e_9 


L 





Extensio 


l ground terms 


sk_l = + 


u, _2) — > e_7 = e_10 


L 





Extensio 


l ground terms 


sk_l = + 


u, _1) — > e_7 = e_9 


L 





Extensio 


l ground terms 


sk_l = u 


> e _7 = e _8 


L 





Extensio 


l ground terms 


1 = +(u, 


_2) — > e_6 = e_10 


L 





Extensio 


l ground terms 


1 = +(u, 


_1) — > e_6 = e_9 


L 





Extensio 


l ground terms 


1 = u — 


> e_6 = e_8 


L 





Extensio 


l ground terms 


1 = sk_l 


— > e_6 = e_7 


L 





Extensio 


l ground terms 


+(u, _1) 


= +(u, _2) > e_4 = e_5 


L 





Extensio 


l ground terms 




_2) > e_3 = e_5 


L 





Extensio 


l ground terms 




_1) — > e_3 = e_4 


L 





Extensio 


l ground terms 


sk_l = + 


u, _2) > e_2 = e_5 


L 





Extensio 


l ground terms 


sk_l = + 


u, _D > e_2 = e_4 


L 





Extensio 


l ground terms 


sk_l = u 


> e_2 = e_3 


L 





Extensio 


l ground terms 


1 = +(u, 


_2) — > e_l = e_5 


L 





Extensio 


l ground terms 


1 = +(u, 


_1) — > e_l = e_4 


L 





Extensio 


l ground terms 


1 = u -- 


> b_1 = e_3 


L 





Extensio 


l ground terms 


1 = sk_l 


— > e_l = e_2 


L 





Extensio 


l ground terms 



Finally we hand over to a prover (Yices is default here). The program checked 
earlier that the problem was in a decidable fragment of the theory of arrays 
(APF), which is if - - local. Hence Yices' answer can always be trusted irrespective 
of whether the answer is 'satisfiable' or 'unsatisfiable'. 



The problem is in APF 
Handing over to Yices : 
Total number of clauses : 109 . 

unsat 
unsat 

H-PILoT spent 

Of which clausif ication took 
The prover needed 
Total running time: 



0.161975s on the problem. 
0.006998s. 

0.021996s for the problem. 
0.183971s. 



15.3 Model generation and visualization 

We illustrate the method for model generation we use on two examples. 
Example 1: Theory of pointers 

Consider the following problem, specified in H-PILoT input syntax: 



System Description: H-PILoT 
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Base_f unctions :={(+, 2) , (-, 2)} 

Extension_f unctions :={ (next , 1, 1, pointer), (prev, 1, 1, pointer), 
(priority, 1, 1, pointer, real)} 

Relations :={(>=, 2)} 

Constants :={ (null , pointer), (a, pointer), Cb, pointer)} 
7. K 

Clauses := (FORALL p) . prev (next (p)) = p; 

(FQRALL p) . — > next (prev (p)) = p; 

(FORALL p) . priority(p) >= priority (next (p) ) ; 

Query := priority(a) = _5; priority(b) = _6; a = prev(b) ; 
7,NQT(a = null) ; % pivotal for satisfiability 
NQT(b = null) ; 



We used CVC3 to generate a model for the set of clauses obtained after the hier- 
archical reduction. A partial model is given below (after preprocessing/deleting 
repetitions): 



null = a 

prev(b) = a 

prev (a) = d_5 

next (prev (prev (b) ) ) = e_5 

next (prev(b) ) = d_l 

next(b) = a 

prev (prev (b) ) = d_5 

prev (next (prev (b) ) ) = d_5 

prev (next (b) ) = d_5 

prev (next (a) ) = d_5 

next (a) = d_l 

priority (next (a) ) = 

priority (next (prev (b) ) ) = 

priority (prev(b) ) = 5 

priority(b) = 6 

priority(a) = 5 



We can make this model total by defining next(a:) := null and prev(y) := null 
whenever next(x) resp. prev(y) are undefined (cf. Section 11.2). The obtained 
model can be visualized using Mathematica (this last step is currently performed 
separately; it is not yet integrated into H-PILoT, but an integration is planned 
for the near future.). The result is presented below. 

IW Gr8phPl<*[(['Duli" -* "null", "prev"}, ("b- t 'null", -pit**}, {"S>" * "null*, -next-}., 
("null.' -i "dl", "nait"), ("di -1 ■» "null", "prav-J, ("dl" .* "mill", "na*"}], 
VertesLabeling -t True, DirectedEdges -> True, Mult iadge Style 1 I.!, SeltLoopStyle -t 0.2] 
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Example 2: Theory of functions over the real numbers 

Consider now the following example: decide whether 

Mon/UMon 9 |=r Vx, y, z, u, v(x<y Az<y A/ \y)<g{u) Au<v Au<w — > f(x)<g(v)). 

We formulate a satisfiable version, by replacing the argument x in the conclusion 
with a new variable xo- The problem obtained this way can be formulated as 
follows in the input format of H-PILoT. 



Base_f unctions : =0 

Extension_f unctions :={ Cf , 1), Cg, 1)} 
Relations :={(<=, 2)} 

Clauses := (FORALL x,y). x <= y — > f(x) <= f(y); 

(FORALL x,y). x <= y — > g(x) <= g(y) ; 

Query := cl <= dl; c2 <= dl; d2 <= c3; d2 <= c4; 
f(dl) <= g(d2); NOTCf(cO) <= g(c4)); 



CVC3 can be used to generate the following model of the proof task: 



model : 




cO = 1 




cl = 




dl = 




c2 = 




c3 = 




c4 = 1 




d2 = 




g(d2) = 





f(dl) = 





g(c4) = 


1 


f(cO) = 


2 



From this partial model, a total model can be constructed as explained in [Sof08]. 
This model can then be visualized as follows in Mathematica: 

Irfi]. I,lKtLlnePl«ttt(l-2. 10. Qly V* 1}j M^i °J. 0); £1. S) . [*. 2»J] 



PUD, 




Note that if we require differentiability of / and g then - with the completion 
described in the previous example - monotonicity of the extensions may not be 
preserved: 



System Description: H-PILoT 
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ir«|, fl = Iiit*rpol_fiti_on[ ((-2. 0), {0. 0}. (1. «.}• C. l}>1 

Oitfal- Intfttpoieti (i^Fj(u:tion| ( ( - 2 y d|J, <:^) 

ni-l- rntarpol_atl_tjn[ ( {-2, 0), f0 + Oj, (1 , 23 + 2>}] 

cui: I- In teirpolatingFunct ionj | | -2 , <>J 
Lfil - Plot[lfl|iJ, '21*3}, -2. ij] 



In the example above we can enforce the functions to be linear. A general study 
of the properties which can be guaranteed when building the models is work in 
progress. 



*[u|. *1 h -2, 1), £{03, 0, 1}, <(l} t U V, *. Ul3 

h[i*|. £2 » Interpolation! f{{ -2 j -4, 2), [(0), 0, 2), (£1J. 2, 2J , U*>. 2, 2}J] 

Q'jSi'h mtefpoiaL ingFu ncti on) j ( - 2 , 

M.ot[(fl[i], [i. -2, 1)] 
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